Written by Peter Bortiz    Posted on March 4, 2010

Peter Boritz is the architect and chief technical officer for Snappy Reports XBRL and can be reached via e-mail.

In one of my recent posts, I mentioned the problem of handling changes to labels between filings to the SEC. I noted that:

An element contains a label which provides human readability for spoken languages. There can be only one label for any given language and label category combination. A problem occurs if the label changes from filing to filing…For example, the label “Property Plant and Equipment net of Accumulated Depreciation” is a static label. Typically, however, a label may more likely resemble “Property Plant and Equipment net of Accumulated Depreciation of $x and $y”. This label is no longer static, because the values of $x and $y are tied to the filing based on data facts within the filing.

An optimal reporting solution to this problem would minimize changes to the extension as much as possible; this would provide maximum reusability and minimizes labor costs and time. Three solutions present themselves: cloning, footnotes, and formulas.

Cloning
One solution is to clone a new extension for each filing and then change labels for each clone. Utilities may be used to clone one filing to another. This gets cumbersome, however, and it requires manual operations and extensive quality control review. This solution is not scalable and is the most primitive of the options presented.

Footnotes
Another option is to keep the label as a constant and use a footnote to denote the variable portion. This solution works nicely. The taxonomy label remains “Property Plant and Equipment” for all filings, but each filing would footnote the variable portion of the disclosure as “net of accumulated depreciation of $x and $y”.

The problem with this solution is that many viewers do not display footnotes – most notably, the SEC’s. Their viewer may be the yardstick with which your clients and peers are measuring the quality of your work. The reality is that your clients and peers need to see a complete rendering that includes everything. The use of footnotes to disclose the variable portion of labels works nicely, but it is missing a mechanism for quality control purposes.

Formulas
The best choice is to use the same extension without the use of footnotes to accent labels. This can be done with variables.

A variable in a filing pulls the instance value for a specific element and context combination. This is particularly handy with labels and disclosures. Variables are defined in the XBRL functions and formulas specification. However, the specification does not apply variables to labels. We can use a subset of functions and formulas for processing labels.

Our goal is to derive one or more instance values based on variables. For a specific element, we may want to obtain the current instance value for the current period or previous period. A previous period may be a year, semester, or quarter for an equivalent period in the previous year.

Our label problem with may be solved with pseudo syntax similar to:

Labor Expense including stock-based compensation of
{ GetValue(us-gaap:StockBasedCompensation,CurrentDuration<12>):$#,###,##0 } and
{ GetValue(us-gaap:StockBasedCompensation,CurrentDuration<12> – 12):$#,###,##0 }

The above is a fabricated syntax for display purposes only. We are telling an XBRL processor to make two substitutions in our label. Based on a given element, we are getting the data facts for a specific reporting period. The syntax is:

    GetValue(Element, Reporting Period<Length> – months)

For example, we are taking the current 12-month duration (current year) and comparing it to the equivalent reporting period in the previous year (Period – 12 months). If our current period is year ended 2009-12-31, then year minus 12 months would be 2008-12-31. The beauty of this is that our syntax is relative to our filing and it is totally reusable.

In the first instance, we are taking the value of stock-based compensation for the current period and placing its value in the label labor expense. For the second portion, we are asking for the equivalent value for the previous year; it could also be for the prior quarter, or an equivalent quarter in the previous year.

The “funny piece” I have included is $#,###,##0. We need a way to tell the processor how to format the number. In this example, I am using standard Microsoft formatting code to format the value with a preceding dollar sign, thousands comma separated, and no decimals.

The processor makes the required substitutions and places them into the label at run time. This means the same functionality always pulls applicable values based on your current filing period. Once you set the label, you never have to change it from filing to filing. This solves scalability issues and makes our life easier.

The instance or report would display the label similar to the following.

Labor Expense including stock-based compensation of $1,000 and $1,200.

Function is an important aspect to dynamic labels. We are not always looking for the value of the data fact. We may also be looking for a date value based on context — for instance, cost of sales of $1,000 as of 12-31-2009.

A formula for obtaining a date may look something similar to the following.

{ GetDate(CurrentDuration<12>.– 12,End):MM-dd-yyyy }

GetDate returns a binary date/time. You can format it any way yhou want. The format yyyy would return the year only, as in 2010. European dates are dd-MM-yyyy. Another option is to use localization. This would set the date format according to the localization set in the computer. GetDate requires either an End or a Start parameter for duration periods. You need to know if we are requesting the date at the start or end of the period.

The use of formulas may also be handy in disclosures where the text block makes reference to the value of an element elsewhere in the taxonomy. For instance, if a numeric value within a disclosure refers to an element, a formula could be used for populating the numeric fact within the disclosure. This not only provides reusability and scalability within your filings over a span of time, but it also sets you up for detail tagging. The formula not only obtains a value, but it also identifies that the element from which the data is being pulled is a detail tag for that disclosure.

If force of habit requires you to always use formula based numeric facts within your text blocks rather than static text-based numbers, you would have fairly high assurance that your detail tagging is complete and reliable for all detail tagging within the filing. The detail tag would be the element referenced in the formula.

Written by Margot Brandenburg     Posted on February 25, 2010

Margot Brandenburg is an Associate Director at the Rockefeller Foundation in New York City, where she leads the social and environmental performance component of their Impact Investing program initiative. 

Much has been made over the past year and a half of the outsized (and, it turns out, unsustainable) returns being made on Wall Street, and the negative externalities of those investment decisions for taxpayers and the public. This phenomenon, enabled by opacity, non-disclosure, and ill-purposed “creativity” in accounting and reporting, is itself a reminder that XBRL and related pieces of information architecture have  a critical role to play in the standardization, transparency. and exchange of information about company and investment performance. Perhaps greater implications for the future of XBRL, however, come from a countervailing trend: the rise of impact investing and related strategies for integrating social and environmental impact in investment decisions. 

There are a number of ways investors can incorporate social and environmental considerations into the due diligence and management of their investments. For purposes of simplification, it is perhaps easiest to group these into two categories: helping or requiring companies to do “less bad,” and helping or requiring them to proactively “do good.” The line between the two is arguably a blurry one, and may lose its distinction entirely in certain cases. Nonetheless, it is a helpful starting point for understanding the multiple applications of non-financial information in investing.

Activities that fall into the first category – helping companies do less bad – are typically employed with respect to large, publicly traded companies. They may take the form of shareholder resolutions or divestment strategies at the company level, or investment screens at the fund level, where fund managers avoid investments in whole industries or geographies (e.g., tobacco, Darfur) or in the worst-performing companies within a given industry (such as the coal company that pollutes more than its peers, etc.). According to a recent study by the consulting firm Booz & Co, 7% of all global assets are now screened. In the US, the US Social Investment Forum estimates this figure to exceed 11%.

Screening and related strategies for encouraging corporations to do less bad received a huge boost last month, when the SEC issued a rule providing interpretive guidance to companies for reporting on the climate change-related dimensions of their activities. The role of XBRL in facilitating the communication of climate change-related data has already been codified through the Global Reporting Initiative, a framework for sustainability reporting that became the first of its kind to utilize an XBRL taxonomy (see Sean Gilbert’s post on this blog). Additional frameworks, such as that of the Carbon Disclosure Project, may soon migrate to an XBRL standard as well. The recent SEC ruling may also pave the way for mandating the disclosure of additional dimensions of non-financial performance, such as those related to water, human rights, etc. – all of which would be usefully reported and communicated using XBRL.

While smaller in size than screening, impact investing — investments in companies and funds that actively seek to generate a positive social and/or environmental impact while providing a financial return – is also poised to play an important and growing role in the coming years and decades. Impact investing includes sectors like microfinance and clean technology, where it has penetrated mainstream investment activity, as well as emerging sectors like water, health, and agriculture. A 2009 report by the Monitor Institute, Investing for Social and Environmental Impact, describes the rise of activity in this area and estimates that it could grow to 1% of total assets under management (estimated to be $30 trillion at the end of 2008).

Impact investing lies somewhere between philanthropy and purely commercial investment activity, in a ‘murky middle’ that is often still sub-scale, confusing, and fragmented. However, there are powerful indications that it is growing in size and coherence. Within the past few years, investment banks have launched social sector finance units, pension funds and insurance companies have created dedicated social investment funds (often alongside of negatively screened funds), and a proliferation of foundations and family offices have concentrated their assets in this area. The diversity of impact investors is matched by the range and creativity of business models that are putting this type of money to work, from microfinance banks in Cambodia to solar panel manufacturers in Ohio to agricultural cooperatives in Tanzania. In between them, a number of specialized fund managers, investment vehicles, and service providers have emerged to facilitate the intermediation of capital. The participants in this marketplace are primarily still private actors, and the mainstay of its activity remains largely outside the purview of the SEC and other regulators. However, investors, funds, and company managers active in impact investing all require extensive information on social and environmental — as well as financial — performance, and thus represent a large source of demand for new applications of XBRL.

The Microfinance Information eXchange (MIX) became the first organization to publish an XBRL taxonomy in service of the impact investing industry, and it was recognized by XBRL International in 2009. The MIX’s Microfinance Taxonomy 1.0 is (as one might expect from the name) specific to microfinance, which is but one sector within the broader impact investing industry. The Global Impact Investing Network (GIIN) recently published v1.0 of an XBRL taxonomy called IRIS (Investment Reporting and Impact Standards), which is designed to service a broad range of sectors and activities within impact investing. IRIS includes microfinance – and incorporates relevant elements of the MIX taxonomy for this purpose – as well as domains such as environment, community development, health, and agriculture. Like the broader impact investing industry itself, IRIS lies at the intersection of profit-making and social-purpose motivations: it emerged as a partnership between non-profit organizations whose mission is to find and scale solutions to the world’s most pressing problems, and for-profit companies with expertise in the areas of accounting, auditing, and business reporting. [Disclosure: Hitachi Consulting is one of the for-profit companies – ed.] 

The creation of the IRIS taxonomy enables the industry-level data aggregation and benchmarking that are crucial for setting performance standards for this hybrid area of investment activity. These activities are being undertaken by the GIIN, with a combination of support from private and non-profit partners. The IRIS taxonomy is also being embedded in a number of related products and information services, such as portfolio management software and rating systems (notably the Global Impact Investing Rating System, or GIIRS). Standard definitions and data elements, which form a common language, must serve as the basis for the myriad pieces of infrastructure that the emerging impact investing industry requires.

The diversity of activity represented within impact investing will also require the exchange of batch data between sector-specific aggregators of information and industry-wide stewards such as the GIIN. Here too XBRL has a critical role to play. The IRIS and MIX teams are currently collaborating on the development of technological infrastructure to communicate data, using XBRL as the means of exchange. They are, moreover, doing so in such a way as to maximize the scalability and extendibility of the solution so that it can, in a future phase, support exchanges with other organizations and in additional sectors.  

More information on impact investing is available on the Rockefeller Foundation’s website or on that of the Global Impact Investing Network.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. And once again, the deadline?

March 19.

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

Christopher Whalen is co-founder of  Institutional Risk Analytics (IRA) and provides consulting services for auditors, regulators, and financial professionals. He edits The Institutional Risk Analyst, a weekly commentary on the institutions and financial markets that comprise the global political economy. He contributes often to publications like the New York Times and Barron’s and appears regularly on CNBC. He has testified before the US Congress on a variety of financial issues.

1. In an interview with this blog about a year ago, Neal Hannon said:

The biggest underreported story about XBRL in the US is the FDIC. During the recent financial crisis, the almost two years’ worth of quarterly data collected in the XBRL format has given the Treasury Department valuable insight into which financial institutions have suspect holdings.

Others have taken a more skeptical view, which at the extreme may be stated as “If the FDIC implementation was so great, why didn’t it do anything to stop the financial crisis?”

What do you think? What are reasonable expectations for the role data standards in general and XBRL specifically can play in providing stability to financial systems?

Neal Hannon is entirely correct that the implementation of XBRL and other technologies by the FDIC has revolutionized the collection, validation, and distribution of bank Call Report information. But as my partner Dennis Santiago often notes in XBRL discussions, information collection is only half the job. Analysis, judgments, and decisions still need to be made downstream of the data repository. Whether or not regulators and politicians in Washington do the right thing when it comes to public policy choices has no direct relation to using XBRL to increase data transparency and accessibility, which is still the exception rather than the rule in most countries. The FDIC’s data collection effort inclusive of XBRL is the finest such public data resource in the world and is virtually free of errors. Sadly, this is the exception to the general state of non-disclosure in many industrial nations,  even major nation states in Europe and Asia, where there is no public right to know. The FDIC data is a very unique resource, and XBRL is just one of many tools employed by the FDIC to make it truly world class. 

I don’t understand the objections raised by people that say “XBRL didn’t do anything to stop the financial crisis.” Such statements reveal an uninformed and self-serving world view that is refuted by the facts. Dennis and I have been looking at and analyzing superbly collected and disseminated FDIC bank data since 2003; but it must be said that the FDIC’s attention to data quality has been around a long time, decades in fact. Anyone who follows our work knows that we, along with many others, have been calling attention to the problems in data quality in many financial markets. Not everyone was deluded by the sloppiness. Nassim Taleb rightly accused the financial community of this in his “Black Swan” indictments. The reality is the community conspired to make the markets even more opaque and less transparent, thwarting the basic premise behind efforts such as XBRL, namely that everyone wants greater transparency.

For example, had the data tagging, collection, and distribution protocols of XBRL been adopted in areas such as residential and commercial mortgage loan securitization and OTC derivatives, they might indeed have been made more apparent and large portions of the financial crisis might have been averted. But that wasn’t in the business interest of the purveyors of these instruments. Remember, virtually all of these toxic securities were brought out as “private placements” via Rule 144A and are thus not registered with the SEC. So criticisms of XBRL for not helping to prevent the financial crisis in this respect are quite outrageous. My hope is that in the future, perhaps through the adoption of new regulations on bank securitization by the FDIC, we will see mandated public disclosure of all OTC securities and derivatives.

These problems of opportunistic opacity continue to this day. Look at the way that the International Swaps and Derivatives Association (ISDA) and the OTC dealers are dragging their feet on the standardization of FPML, the XML dialect chosen for tagging OTC derivatives transactions, and you can see the root of the problem. We have created a culture of deception and concealment in our financial industry that seeks to hide price and other data from the public to maximize monopoly profits from trading OTC securities and derivatives. The entire retrograde construct of OTC derivatives and securities is ripe for revolution when it comes to using XML dialects such as XBRL to make these data sets available to investors and the public. I think that is a very exciting and positive message for the XBRL community and for public policy in general, but this great technology is also a threat to many entrenched constituencies in the banking world who hate transparency and fear greater openness. 

2. In a post you wrote for this blog about three years ago, you did discuss the benefits of the FFIEC implementation of XBRL for Call Reports and noted that “…the data collection and validation tasks are clearly a big winner and have saved [the FDIC] enormous amounts of money and man hours in terms of collecting financial statement data from US banks.”

But you also said that the argument for XBRL was strongest at the “upstream,” agency level; in relative  terms, the business use case at the “downstream,” end-user level was “not yet mature enough and powerful enough to withstand the critical scrutiny of business case needs.”

With respect to the FDIC, do you still hold that view?

Yes we certainly do continue to hold to the view that the use case optimization of both “upstream” and “downstream” technologies follow separate discovery paths. This point is borne out in the real world. There is absolutely nothing wrong with insisting that regulatory reporting and data collection continue to become more structured via some organizing construct like XBRL while at the same time insisting that the downstream delivery of information from those central libraries to the many types of analytical engines used to support decisions remain as diverse and multilingual as possible.
 
The actual operational implementation of the Central Data Repository (CDR) by the FDIC validates our judgment about the benefits of XBRL to the process of collecting, validating, processing, and then distributing this data to a myriad of different consumer groups. If we trace the production and use case process, those benefits become obvious. Upstream the benefits are equally dramatic. They manifest as efficiency and quality improvements.

First, think of the FDIC-insured banks using the XBRL template to submit their Call Reports to the FDIC. The logic in the XBRL taxonomy allows the supervisory personnel at the FDIC to identify and correct any errors that may be made in the filing process.  Anomalies are flagged and, where appropriate, are then subject to additional supervisory review. The process is transparent enough that we can observe it in real-time on the FDIC web services system. The benefit of XBRL has been to greatly increase the productivity of the review process and decrease cost in terms of personnel, and also improve accuracy to the point where input errors are basically eliminated. This issue of accuracy is of crucial importance to our firm, because we serve more than 20,000 retail consumers who use our automated bank ratings to inform their individual and corporate asset allocation choices in terms of bank depositories. It’s even more critical for bank counterparties who need to determine whether to extend business credit to a bank or demand payment in cash. And finally data completeness and timeliness at one regulatory agency, the FDIC, is what enables us to deliver powerful benchmarking services to other agencies, such as the SEC, to perform their mission.

Next, there is internal processing to meet a variety of internal and external consumption needs. The data in the XBRL files is parsed into numeric data to support several dozen internal supervisory and reporting applications within the FDIC and other agencies in the FFIEC. Some of these use cases involve modern desktop applications for data analysis, while others feed legacy mainframe data applications that literally go back a quarter of  a century and often feed single use case needs that are driven by law and regulation. Then we have several version of the data, including XBRL documents and legacy CSV outputs that are tailored to meet the specific commercial needs of external rating agencies like us as well as the research and policy needs of government agencies and educational institutions. The FFIEC CDR downstream service layer supports PDF, CSV with a filename suffix of .SDF, and XBRL.  Of interest, my partner Dennis notes that the downstream delivery standard evolving across the multiple government agencies we keep track of these days is steadily headed in the direction of PDF for reading by humans and flavors of CSV for interfacing machine-to-machine. Additional popular flavors include XLS for small data sets, SAS XPT for statisticians, and plain vanilla-XML as a verbose substitute for CSV.  In all cases, the downstream analyzers have little need for the perfect accounting compliance and categorization constructs of the XBRL collection layer. These users quite reasonably demand the data is cleaned of such overhead before it ever gets to them so they can perform their work with optimum productivity.

Finally, there is public distribution. If you look at the way in which a firm like ours consumes the FDIC data, the point regarding upstream versus downstream benefits becomes clear. Our primary need regarding the use of FDIC data is the calculation of arithmetic relationships and metrics to drive our bank performance and ratings model, The IRA Bank Monitor. We consume the FDIC data in two ways. 

First, we gather the bank Call Reports dynamically from the FDIC CDR facility in real time and harvest the data into a database structure that allows us to calculate preliminary ratings for a particular bank unit. The enablement by XBRL-based data collection has an enormous benefit here in terms of accuracy and timeliness, and has cut several weeks off of the waiting time for accessing many bank Call Reports. The preliminaries appear in the same timeframe as the SEC K/Q filings. We actually use the CSV output format from the FDIC.  It’s purely a machine efficiency decision. Given known good data, one is actually indifferent to the format in which it’s delivered.  The processing time is easily an order of magnitude faster for database injections with CSV than with XML. Remember that our firm is running individual and peer group level analytics on thousands of banks per quarter in an SQL environment, so the efficiency of the data transport and calculation regime is critical to providing a data analytics product that is up to commercial grade for both institutional and consumer users. 

The second part of our data collection process involves the importation of the entire body of data from the FDIC in a legacy format which essentially recapitulates and confirms the CDR data we have already collected. We process all of the data, metrics, and ratings for the entire universe of FDIC-insured banks and then finalize the results for that quarter.  As I write these comments, it is the first week in February 2010 and we have collected about 7,500 Call Reports from the FDIC CDR. Of interest, the CDR also enables us to calculate and publish a preliminary Bank Stress Index (BSI) rating for all of the banks which have reported to far, providing our clients and readers of our free commentary with access to data about the condition of the US banking industry several weeks before the FDIC press conference. Since timeliness is the key data consumption priority  for most investors, the decrease in wait time due to the implementation of XBRL by the FDIC is a huge win for consumers of bank data and ratings.

IRA Preliminary Bank Stress Index (BSI) Grade Distributions — Q4 2009

Source: FDIC/IRA Bank Monitor

3. What is your overall opinion of the SEC’s XBRL mandate in terms of the burden it places on business and its usefulness to both agency personnel and end users?  

My view of the current tagging regime at SEC is that this is still a work in progress. As a bank analyst who covers over 20 publicly traded financial institutions, I don’t find nearly the same level of utility in the XBRL-tagged documents on the SEC website as I do using the bank level data from the FDIC, which as I’ve explained we have implemented into a complex model of metrics and ratings. In essence, all of my work in terms of bank unit analysis is “ready to eat” because of the way in which my partner Dennis has leveraged the upstream tagging and characterization power of XBRL to enable our downstream analysis systems. But by the time we reach the consumption phase, we are using tools like SQL to analyze subsets of the XBRL submissions, primarily the numeric values and pre-calculated metrics provided by the FDIC, instead of consuming the entire XBRL document.   

When my analysis work turns to looking at the SEC filings for Citigroup or Goldman Sachs, for example, the tagged documents on the SEC website are fun to play with and provide some utility in terms of display. Ultimately, however, the tagging of footnotes and data elements in the XBRL files on the SEC site are not yet saving me much time in terms of overall work process. Compared with the highly automated analytics possible with the FDIC data, the SEC disclosure is what we call “chopped salad” in the financial data world. The key issue here is that XBRL and the related accounting taxonomy have not changed the fact that each bank I cover is allowed under GAAP rules to vary their presentation of results in some very significant ways. Whereas the FDIC bank unit data is tightly defined and reasonably consistent, the presentation of bank financials under GAAP is far more subjective – and deliberately so! Public disclosure is not a photograph or x-ray of a company’s financial performance, but instead is closer to an oil painting, with or without XBRL.   

So if I were to line up the most recent 10-Qs from Citi, Goldman, and Morgan Stanley side-by-side, you will find some very significant differences in how key elements are described, defined, and presented, such as off-balance-sheet vehicles and the way in which losses from these activities are disclosed. Some banks charge-off loss via the loss reserve account, others bury the losses as non-interest expense.  The fact of tagging of footnotes always is several quarters behind the current state of the art of investor relations at my banks. So since we cannot yet seem to keep the XBRL taxonomy current with the ways in which banks are allowed to disclose (or not disclose) material aspects of their financial performance in the current reporting period, the human brain and the Excel spreadsheet remain the most effective tools for working with SEC filings.

4. In his January 2009 whitepaper Bringing Transparency to the Mortgage-backed Securities Market, Philip Moyer of EDGAR Online describes the benefits he believes XBRL in a centralized MBS reporting system would bring, including better data quality, historical comparability, and reduced reporting costs (see pp. 17-18).

How useful do you think XBRL can be in bringing transparency to the MBS and other securities markets that have been at the heart of the financial crisis?

As I indicated in my earlier comments, the use of XBRL or perhaps another XML dialect is obviously attractive. My partner Dennis, who started his career in finance in the fixed income modeling world by installing an MBS software package in the Pasadena offices of Countrywide in 1991 after a decade at Rockwell International, thinks XBRL might be both overkill and undergunned for this purpose. He thinks a simpler XML structure suitable for easy integration by servicers would suffice for collateral data reporting in MBS.  And he thinks deal rule modeling — that can involve complex mathematics – might be better served by adapting from techniques pioneered by the Department of Defense community. Like most of his peers in the world of data operations, Dennis is pragmatic about using the right hammer for the right nail, because (1) cost and (2) production efficiency are the two key criteria in the world of big time securities clearing and data processing. 

Given the relatively less complex nature of the information to be gathered, you could probably develop an XML-variant that was both complex in its vocabulary but relatively easy to transport compared with say an XBRL document filed with the SEC by a public company. In fact, there are already a number of well-tested XML dialects in use in the world of securities trading and clearing, so my guess is that the DTCC and other financial institutions would default to the version of XML with the least overhead cost.  Remember that the Fedwire and private processing systems are part of a highly developed, highly-automated market where XML is very familiar and timeliness and per unit processing costs are the overwhelming priorities. So I would not suggest that XBRL US spend a lot of time trying to sell itself to the clearing community. 

5. Your December 2009 paper Is It Possible to Re-Privatize the US Financial System? traces the growing role of government in US banking over time and discusses the creation of an “Alliance of Convenience”:

  “…Our spendthrift government, the Federal Reserve System and the TBTF [too big to fail] banks together now comprise the paramount political tendency in America today… Until we break the Alliance of Convenience between the Congress, the Fed and the large, TBTF banks and force our public officials to embrace core American values regarding transparency, insolvency and accountability, we will not in my view find a way out of the crisis.

Clearly this muddle requires much more than an XBRL solution. But do you see a role for XBRL in helping to provide the required transparency?

No, the data from the Fed and Treasury is pretty transparent and is actually tagged already with some relatively simple versions of XML. The Fed, for example, makes all of its financial data available in a statistical version of XML. The one area where an XML dialect like XBRL might be useful is the OTC dealer community, but as already noted, the FPML dialect of XML has already been selected by the dealers for tagging OTC derivatives and complex structured securities.

The real trouble here has nothing to do with the data itself or the structure. The problem is that the data is not public and the dealer banks do not want to standardize these financial instruments nor the XML-dialect used to report on them because doing so would impair their monopoly power over the OTC market. As in the case of SEC disclosure, it is always important to remember that the predominant tendency on the part of human beings is to limit disclosure and thereby increase pricing power. Increased disclosure is always bad for monopolies and this must be fought every step of the way. This is why I have been such a consistent critic of OTC derivatives. The lack of transparency and disclosure in OTC derivatives is unfair and violates the most basic American standards of openness in financial markets. The OTC derivatives market of 2010 is like a bucket-shop from the 1920s, but few Americans seem to appreciate such distinctions today.

6. In your speech last year to the American Enterprise Institute (AEI) and Professional Risk Managers International Association, you said:

Believe me when I say that we have seen the wild eyed, "don’t you get it" look from…our colleagues in the XBRL community. We love their idealism and their vision, and we share same. But we at IRA also live in the real world of operating and delivering decision support systems for investors and fiduciaries.

Could you expand on these thoughts? In what ways do you think the XBRL community is being “other worldly” in its goals and activities?

New technologies have an allure of transformation and value creation that makes people very excited until you actually try to implement and integrate it into the real world.  The creation and implementation of XML, for example, has been relatively successful in that regard.  We’ll see how it goes now that the initial invention phase has finished and — like all technology — the proof of the pudding turns to the tradeoffs of efficacy versus the cost of operations and maintenance.

At IRA, we like to always be mindful that there is nothing really new in technology. The basic building blocks of today’s software and hardware tools trace their legacies back to the origins of computing. Each step of the way, in terms of innovation, there are choices and tradeoffs. We like to always look at the technology innovation process as a quilt, where data and business case needs interact and the best choice, depending upon those business needs, makes itself apparent as part of the diligence process.  Each one of the client silos we serve – consumer, institutional, B2B – have different technical needs and business objectives, and different consumption requirements. We see the world of XML as important building blocks that enable data collection and interoperability between systems, but they do not address the entire solution in terms of consumption. We would not be so bold as to pre-judge how our consumers use the data and ratings we supply.  We prefer to listen, add our perspective, and then give the user the solution that makes the most sense for their needs.

7. In comments made to CFO.com back in 2006, you agreed that an XBRL mandate for financial reporting would expand coverage of smaller companies. Are you still optimistic that this will happen? Overall, given the difficulties of the equity research industry, how do you see the impact of XBRL on its business? Do you believe that, as advertised, XBRL will help the industry cut costs and expand coverage?

Possibly, but not because of the way the SEC or big accounting has handled the implementation to date. What we’ve heard from the smaller SEC registrants community is that XBRL is an extra step that one’s filing vendor does for you as part of preparing and submitting to the SEC. The tagging has not been internalized by the filer nor made part of their internal data collection and reporting process. 

The question about the data vendors that article addressed turns on whether the implementation at SEC results in a useful repository to power an operational downstream analysis solution like the FDIC’s architecture or will just be a demonstration facility. Or to put it in very blunt commercial terms, when I can download the XBRL documents or a subset thereof containing the numerical information in SEC filings, then the existing data vendor monopoly on structured financials will be near an end. The SEC has always taken an evolutionary approach to data collection and dissemination. I suggest that it is time for the SEC to target the distribution of full tagged financials, starting with income statements, balance sheets, and statement of cash flows, as the next practical goal in terms of EDGAR modernization. While the SEC data is still “chopped salad” in terms of accounting presentation, having the data in a consistently structured, “as filed” form would be helpful. Today analysts go to each corporate web site and download disparate Excel and Adobe files to perform analysis. 

8. In addressing the problem of extensions in taxonomies, Gerald Trites of XBRL Canada said:

….Too many extensions by different companies contribute to noncomparability, because each company is likely to do an extension for basically the same problem in a different way. So the results become difficult to compare. One way to address this is to develop very robust taxonomies, such as those in the United States. However, the problem this creates is that the more robust the taxonomy, the more difficult it is to do the mapping required. So robust taxonomies can be an impediment to adoption.

What are your thoughts on the extension issue? What do you see as the relative positives and negatives of a core US GAAP taxonomy with roughly 17,000 elements?

I agree with Mr. Trites’s statement. The way to make XBRL relevant to investors and analysts would be to start with the basic reporting template available from the commercial data vendors and build a very simple data delivery function that expands the completeness of numeric data from income statements, balance sheets, and cash flows. The current SEC data implementation leaves the data monopoly of the large commercial vendors intact, thus no progress in terms of innovation by downstream users.  

The other point that must be made is that complexity of the XBRL taxonomy is a function of the business case needs of the audit profession and has very little to do with how institutional investors consume data. Remember that most of the people who work on Wall Street are focused on quantitative analysis and don’t have a clue how to perform the fundamental analysis of a bank or company. When you look at the size of the XBRL taxonomy, the only reasonable conclusion is that the audit firms are trying via stealth to turn the relatively subjective world of public company reporting into a more deterministic exercise requiring the constant services of a FASB rulings subject matter expert. Anyone who has read the Securities Act of 1934 and is familiar with the legal mandate of the SEC vis-à-vis public company reporting knows this result, apparently sought by the audit firms, is impossible in practical terms, unlikely in political terms, and conflicts with the SEC’s mission of making it possible for ordinary people to actually see and understand what’s happening in the public securities markets.

9. There has been much discussion about the potential of XBRL for internal management reporting.  Actual implementations, however, are few. As the SEC’s XBRL mandate proceeds, do you think XBRL’s use for internal reporting will increase substantially?

No, as my previous comments suggest. The audit firms would like to see XBRL extended to internal reporting, but for many practical reasons companies are going to fight creating an explicit link between internal management systems and external reporting. In every bank that I cover, there is a set of GAAP books and a set of “managed” books. The two worlds only meet in the CFO’s office when it is time to make public disclosure. The same goes for commercial manufacturing, retail, and service businesses. The reality is that management systems technologies such as ERP are light years ahead of accounting innovations like XBRL. There’s a strong case for CFOs of companies to internally opt to tack on reporting modules to their existing ERP instead of replacing these mission critical solutions with an auditor recommended one that changes both internal forms of corporate governance and control. 

10. XBRL initiatives are now being pursued in a wide range of areas, including corporate actions,  sustainability reporting, and microfinance. What uses of XBRL that go beyond the usual sphere of financial reporting and company accounting systems seem most promising to you?

All of these are promising areas, but the two key questions to ask are: (1) is the data collected going to be made public, and (2) is there any standardization of the data to make it useful in terms of downstream analysis?  In the US, for example, there is a push among many states and municipalities to make property records electronic.  But there is no state-by-state or national template for this effort. This is a huge potential opportunity, but getting the states, the realtors and the courts to agree on a standard is another matter.

11. XBRL has now been implemented for financial reporting in most or all of the major economies, including Japan, France, and Italy, as well as smaller nations like Chile and Denmark. What can the US learn from other countries in implementing XBRL? What can other countries learn from the US adoption?

There are big lessons to learn from the two “wins” in terms of US adoption, FDIC and SEC. The FDIC effort is a success because it represents a standardized, tightly defined implementation that meets specific, legally mandated public reporting requirements.  In the case of the SEC, the benefits are less clear because the task is so much more diffuse and the ability of the SEC to impose standardization is non-existent under GAAP.  That is the key difference between the FDIC and SEC business case paths for XBRL adoption.

Making SEC reporting as deterministic and standardized as FDIC bank reporting is neither possible nor desirable, but that does not lessen the utility of XBRL at the SEC.  Once we accept that reality, then the utility and development path for the SEC adoption of XBRL will become easier and the necessary choices will become much clearer.  The world of public company reporting is always changing as the economy and markets change.  

Staying entirely current with the state of the art in terms of GAAP reporting and investor relations spin is a daunting and probably impossible task given current law and resource constraints. Indeed, it is impossible. The effort to describe and add to the XBRL US GAAP taxonomy reminds me of Franz Kafka’s 1917 essay, “The Great Wall of China,” where he describes how generations of people over hundreds of years worked on sections of the Great Wall, but most never saw it completed nor knew the enormous extent of the entire task. Just as public company reporting evolves continuously and in response to many different internal and external forces, so too the adoption of XBRL will need to remain flexible and be aware that the target is constantly moving. 

Written by Chethan Gorur     Posted on February 11, 2010

Chethan Gorur is the Director of Interactive Data at Trintech, Inc. He is also Chair-Designate of the XBRL International Standards Board.

For many businesses filing their financial statements using XBRL to comply with the SEC mandate, the phrase “extension taxonomy” is a largely misunderstood term.  There is a narrow view that it is only about adding brand-new company-specific elements which do not exist in the base taxonomy (Ex: US GAAP 2009). While adding new elements is definitely one of the purposes for creating extensions, there are many other drivers for creating an extension taxonomy. Even though some of the principles apply for other scenarios, this blog post specifically refers to extension taxonomies as they are used to meet the SEC XBRL mandate for operating companies.

The reality is that almost all of the XBRL filers to date have created a barebones extension taxonomy. Because you’ll be delivering your own unique extension taxonomy to the SEC – and a slightly modified version of the taxonomy with every quarterly and annual financial statement you certify – it’s important to understand the component parts of the document, and some basic rules to help guide you in developing it.

An extension taxonomy is not just about a new set of tags (or elements). Elements are actually very specific pieces of information, and the XBRL US GAAP Taxonomy Preparer’s Guide advises preparers to first determine if it is possible to use more general – and less specific – extension tactics.These higher-level tactics can be re-used in future periods, resulting in much less effort over time.

You can tackle creating an extension taxonomy by thinking about it as an upside-down pyramid: begin with the most general set of extension tactics, and see if that suits your purposes. If not, move to a lower level, where more specific information is required. For the purposes of this blog post, we’ve grouped the twelve methods of extending the taxonomy under four, easily remembered headings, listed mostly by the increasing levels of impact that the tactic will have upon future re-usability.

1. Relationships Help Present Your View

It is recommended that companies perform the following at a minimum: (1) create new Relationship Groups, and (2) change the Ordering of existing relationships defined in one of the Industry Entry Points. These methods of extending the XBRL US GAAP Taxonomy have the most capacity for future re-use.

A new Relationship Group allows preparers to assemble custom presentation relationships between already existing elements, tables or existing groups.

Changing the Order is as simple as reordering the children in an existing list.

In some cases, simply modifying relationships within one of the existing Industry Entry Point taxonomies can be sufficient for a business to complete their own extension taxonomy. For example, you might need to modify the order of a list as follows:

It is also possible to (3) add New Relationships between existing elements. An example would be creating a new calculation for multiple elements.

Preparers can also (4) suppress or change a Parent-Child Relationship; however, this is typically done only to resolve a validation error or calculation inconsistency.

Adding New Relationships or suppressing Parent-Child Relationships both have slightly more impact on future re-use of the extension taxonomy, and should be investigated only after determining if the labeling methodologies below can first do the job.

2. The Role of Labels

The SEC recently presented its findings from a review of the Year 1 XBRL filings recommending that an “element label should match its line item caption”. It is recommended, especially for any kind of tabular data, to modify the labels on elements (especially tabular information) to match your financials.

There are three ways labels could play a part in your extension taxonomy: change the Preferred Label on a Presentation Relationship, add a new Abstract Heading Element, or simply add or change Element Labels.

• Changing a Presentation Relationship’s Preferred Label helps dictate how data is displayed. An example would be to change the preferred label on a line item’s presentation relationship from “Terse” to “Negating”, ensuring that the numerical data displayed for that line item has its sign flipped.
• Adding a new Abstract Heading Element simply provides a new heading, under which child items can be grouped. Preparers should first determine if they can modify the label of an existing abstract element prior to creating a new one.
• Adding or changing Element Labels does not modify the element’s definition or references, both of which are the crucial pieces of data used to define that element. This is always preferable to creating a new element, which is described below under the section on elements, and has less future potential for reusability.

Of all labeling methodologies, the Preferred Label on a Presentation Relationship concept is the most difficult for people to understand, and warrants further explanation. Every tag or element has several different types of display labels, each of which can be used in different places throughout your financial statement without modifying the underlying data.

Different parts of your financial statement can reference different label types using Preferred Labels, changing the information displayed on your financial statement without actually changing the tag itself, or the underlying data. In one section of your financials, you might want to change the preferred label for [Goodwill] to “Period End” in order to display “Goodwill, Ending Balance” on your financial statement.

3. Extensions and XBRL Tables

XBRL Tables are powerful constructs, allowing you to group, display and reformat data – all without changing the underlying relationships between the data included in the table itself. For the purposes of this blog post, we will assume that readers have a basic understanding of XBRL tables and terminology, which can be found in Chapter 5 of the XBRL US GAAP Taxonomy Preparer’s Guide.

There are three ways to extend using tables, add a new (8) Domain Member to an Existing Table Domain, add a new (9) Axis to an Existing Table, and add a (10) New Table.

• Adding Domain Members is one of the most common ways of extending taxonomies, especially as you get into detailed tagging. As an example, the Domain “Major Types of Debt and Equity Securities” might be composed of the following Domain Member Elements: “U.S. Treasury Notes”, “Corporate Debt Securities” and “Equity Securities”. Adding a new Domain Member Element to an existing Domain essentially adds a new table column, into which you can add financial data.
• A table Axis contains one or several Domains. Adding an Axis to a table allows you to group Domains together for more complicated reporting requirements. Imagine that you are reporting “Assets by Type” (your Axis) and need to also break them out by “Assets by Location” (your new Axis). Adding the new location Axis would allow you to create a master column by asset type, under which assets by location could be individually reported.
• Before adding a New Table, first determine if you can modify one of the tables available in the existing XBRL US GAAP Taxonomy Industry Entry Points, either by adding Domain Members or Axes as described above. Adding a new table is more difficult than modifying an existing one – requiring that you modify, create or define additional elements, attributes, and relationships. But in some situations it will be necessary.

The example below illustrates how adding a new Axis can help you group data for more detailed reporting situations than the standard taxonomy might allow. In this scenario, the Axis “Reporting Segment” was added to the original table, facilitating this grouping:

4. Add New Elements Only When Required

So far, so good. We’ve made it through nine of twelve methods to extend the existing taxonomy to suit your unique business situation – all without creating new elements or tags. But in some cases, you’ll need to do just that. As we’ve already said, creating new elements or tags has the most impact on future re-use, so do your best to repurpose what already exists prior to extending using the methods below. This is one of the areas which has the highest impact on comparability of data across companies – and will be one which regulators will watch very closely.

Adding new elements should only be done once the existing taxonomy has been completely reviewed, including documentation on existing elements, to determine if one of the methods above can first suffice. If not, there are two ways to add a new element: adding a new (11) Numeric Element, or adding a new (12) String,Text Block or Other Non-Numeric Element. The scope of this post is not sufficient to cover the ins-and-outs of creating new elements, the details of which can be found in Chapter 6 of the XBRL US GAAP Taxonomy Preparer’s Guide.

There are some good rules of thumb to follow:

• You will usually need to add a new Numeric Element in two situations: if you need to combine two or more line items into a single element or if you need to introduce entirely new financial reporting concepts which are not covered in the existing taxonomy. Every new Numeric Element requires both a definition, and a presentation relationship to at least one other element. When you are adding new elements it is very important that you take the time to document the purpose and reasoning behind the same. It’s usually a good idea to go ahead and develop at least one calculation relationship to one or more other elements for all Numeric Elements you create.
• Adding a Non-Numeric Element (such as a text block or string) is performed when the existing tags don’t meet your needs, especially for block tagging of complete notes, individual accounting policies or tables/schedules. Non-Numeric elements do not participate in calculation relationships and you cannot validate content inside it using traditional calculation relationships.

Conclusion

Extension taxonomy documents are as important as the Instance documents you submit to the SEC. Special attention must be paid to the contents of the extension taxonomy. Extension taxonomies are much more than just about adding new elements; they include changes to Relationships, Labels, XBRL Tables, and more. Even if you have completely outsourced your XBRL preparation, it’s important to work with your outsourced provider to understand what goes into your extension taxonomy since it is one of the documents that you will be filing with the SEC.

Written by Peter Boritz     Posted on February 3, 2010

Peter Boritz is the architect and chief technical officer for Snappy Reports XBRL. He can be reached via e-mail.

Understanding Automated Data Management
It’s important to have a sense of perspective about XBRL: it is a means, not the end, of data reporting. An XBRL system is neither the beginning nor the end of a data point; instead, think of XBRL as a postal system. The starting point begins with an accounting/finance system or other data source and the endpoint is a data repository.

For regulatory filings in America, the starting point is the filer’s accounting/finance system and the endpoint is EDGAR.

EDGAR is a data warehouse that stores pertinent information for internal use and reporting purposes. It is fed from an XBRL-based receipt and validation system, and it is designed around XBRL. The data it stores is architected around US-GAAP. EDGAR’s purpose is processing and reporting filing data.

What lies between the starting point and EDGAR are the filer’s XBRL system and the XBRL receiving processes running at the SEC. Thus, the first task for each regulatory filer is to get data into an XBRL filing. Automated data management can play an instrumental role in this task.

Getting data into an XBRL filing could be a manual drag-and-drop operation using an add-on to Microsoft Excel. This method does not save mappings, though. For your next filing, you would need to start all over again.

A better approach, therefore, is bringing data in from an accounting/finance system, using an automated process. This process is designed to be seamless. Mappings are stored permanently and reused. While setting up such a system requires up-front work for the first filing, the benefits well outweigh the costs.

Event Triggers
The process of getting applicable data from an accounting/finance system or other source into the XBRL filing is triggered by an event. (Generally this event is the closing of the books.) The event triggers a data transfer to the XBRL system, which may be in the form of a direct transfer; XML, character-separated, or fixed-format data file; or an Excel spreadsheet.

How the transfer is achieved is not material — all of the above can work equally well — but the data to be transmitted must be planned in advance.

First, we must determine what data is to be acquired and transferred. Second, we need to define how to map that data to the XBRL taxonomy. Once these determinations are made, we should be able to make the data transfer, then run reports through the XBRL system in order to verify that everything looks good and is close to filing.

After the first filing, this should be a fairly quick and painless process. The first filing requires setup, mapping, testing, and quality control, but once these processes are set in place, life gets easier.

Security
Generally, an issue of data transfer is whether the origin system pushes data or the receiving system pulls it. In the case of XBRL, however, the only option is to push. The XBRL system has no basis of knowing when books have closed in order to procure a transmission. As well, it has no idea of how to go into an accounting system to get the data. There is a security issue in play: few businesses will allow a third-party vendor to reach into the guts of their accounting system to obtain information. It remains more secure, and more desirable, to prepare a push on one’s own terms.

Consistency
Here is a caveat with spreadsheets: typically, spreadsheets are embellished with reporting logic that makes them more readable, but these embellishments cause a mapping issue. What is easier for a human to read is not necessarily machine-readable.

Consider the following example. The element net property and equipment may be embellished in a spreadsheet as net property and equipment net of accumulated depreciation of $x. That may be easier to read (to a human), but, upon export, the suffix net of accumulated depreciation changes with each reporting period. Thus, we would no longer have a constant — net property and equipment — to map to.

Some reporting logic embellishments in spreadsheets can actually impede machine readability. Consider the following fragment of a spreadsheet that tracks changes in operating assets and liabilities:

 
A human can easily understand this: the entries for “Accounts Receivable”, “Inventories”, and “Deferred Costs” refer to changes to each of these values.

A computer cannot take this context into consideration, however. The line for changes in accounts receivable has the title “Accounts Receivable”, so a computer program could merge this with the value for Accounts Receivable. In other words, the machine would conflate the change in a value with the value itself. This is unacceptable; it should not be allowed to happen.

A better approach is directly correlating to the chart of accounts. This means that character-separated, fixed-format, or XML files are better suited as source files. These provide a consistent and direct correlation to the financial/accounting system, which makes the mapping process easier and more manageable.

Text-Based Disclosures
Automated processes work well for financial reports like the balance sheet and income statement, but disclosures present other issues. These generally come from text or “EDGARized” files.

For an automated process to work, a disclosure source file must have a consistent format. In many cases, reporting numeric facts can be automated, but text-based disclosures must be manually dragged and dropped to complete the filing.

Optimally, disclosures can go into a spreadsheet or processable data file with a heading and disclosure body. This would be machine-readable. An EDGARized file may be machine-readable if it contains consistent heading tags. Otherwise, disclosures may process from an XML or character-separated file.

Conclusion
Even considering the challenges listed here, an integrated and automated approach is the best solution for serious filers. Excel spreadsheet add-on programs simply are unable to provide automated integration to financial/accounting systems. The small investment of up-front work required to properly define the integration will quickly pay off in terms of improved functionality and reliability.        
              

Written by Bob Schneider     Posted on January 23, 2010  

For 20-plus years, I have struggled to learn Japanese. A primary challenge has been to remember some 2,000 characters Japan imported from China. Because they derive from ideograms (ie, graphic symbols of ideas), like many students, I have tried to remember the character by looking for the graphical elements of meaning still present within it.

Good luck with that. Among the many reasons this approach is (mostly) unhelpful is that – almost from the beginning — characters were sometimes miscopied, corrupting and confusing the meaning elements within them.

Of course, East Asian characters do not have a monopoly on transcription issues. Numerous scholars are devoted to textual criticism of the Greek classics, seeking to identify, interpret, and remove copying errors. It’s not hard to conjecture some reasons for the mistakes – hard-to-read handwriting, the distraction of a comely Grecian walking past, a scribe with his own agenda going rogue (or at least introducing small variations).

I mention these events of antiquity because ever since computers entered the office, people have been blaming them for screwing things up.  (Film buffs will recall how EMERAC, brainchild of IT consultant Spencer Tracy, fired the CEO at Katherine Hepburn’s company in the 1956 movie Desk Set.) But it’s not the mechanical, automated workings of the computer that are at fault. It’s the manual processes requiring human input and intervention that gum up the works.  

We were sadly reminded of this fact by the misspelling of Umar Farouk Abdulmutallab, the Christmas bombing suspect, in a State Department database. A correct entry may not have prevented the incident, but we do know his name appeared on some government lists and not on others. Certainly the failure to uniquely identify this individual in the government’s information systems points to the utility of “enter once, use many” data entry that minimizes human intervention.

The need for consistency and accuracy in names pertains as well to government financial reporting. Rekeying of financial data is not only costly and time-consuming, but it introduces the same sorts of error and inconsistency that manual processes always engender. Three years ago I discussed the report Transforming Financial Information: Use of XBRL in Federal Financial Management. In describing the benefits of consistency that XBRL would bring to Federal budgeting formulation and execution, the report states:

Having a single XBRL based window for the transfer of information would also eliminate a number of reconciliation points, since budget request submissions and reports would be created from the same underlying data with no manual intervention. XBRL would ensure consistency across all agency financial review reports and reduce the reconciliation burden of the recipients such as FMS, OMB, GAO, and Congress. The transition of the closing package data from PDF or Excel to XBRL would also address cost issues imposed on FMS by receiving reports from agencies that use inconsistent terminology and rules of classification. XBRL would allow all agency recipient entities to utilize a standard vocabulary for all closing package reports.

I can’t find evidence that any progress has been made in introducing XBRL to the Federal budgeting process in the past three years. There has been the recent push to have public companies receiving government bailout funds to use XBRL to report how they spent the money. The bill passed the House with bipartisan support on December 14, and it is included in a larger Senate bill renewing the Federal Financial Assistance Management Improvement Act (FFAMIA). According to a January 5 report in Compliance Week, both branches of Congress have approved versions of the bill, and only minor differences remain to be reconciled before obtaining the President’s signature.

Coupled with the SEC’s XBRL mandate, the Federal government appears to be making significant progress in having companies provide data in XBRL; but it has made less headway in introducing the data standard to its own financial reporting systems. As the bipartisan sponsorship on renewing the FFAMIA indicates, this seems at least one area of public policy that might not descend into political squabbling, and where the benefits of eliminating manual processes in information systems can be obtained.

Written by Peter Boritz     Posted on January 11, 2010

Peter Boritz is the architect and chief technical officer for Snappy Reports XBRL and can be reached via e-mail.

In Part 1 of this four-part post, I offered an overview of the problems associated with XBRL filings; in Part 2, I focused on those associated with the Interactive Financial Report Viewer. Part 3 looked at filing issues in several areas, including taxonomy extensions, negated facts, consistency checks, fact checking, filing path, per share information, and decimals. In this final post, I focus on the detail tagging of footnotes that the SEC mandate requires for companies in their second year of filing XBRL statements.

Technically speaking, detail tagging is a cross mapping of disclosure facts to a reportable element pertaining to the disclosure and any elements that are the subject of the disclosure. These disclosure facts apply to concepts described within the narrative. For example, a disclosure relating to inventory policy may map to both the policies disclosure element and an element for inventory. A detail tag applies to numeric facts within disclosures and refers to elements to which numeric facts pertain.

To put it bluntly, detail tagging is a lot of work. Beginning with the second year of the SEC’s phase-in of XBRL, these requirements are mandated for company financials:

•    Each complete disclosure is tagged as a single block of text
•    Each significant policy within a policy disclosure is tagged as a single block of text.
•    Each table within each disclosure is tagged as a separate block of text.
•    And within each disclosure, each numeric fact (monetary values and percentages) must also be detail tagged.

Detail tagging becomes easier if detail tags map to single paragraphs. Managing disclosures by paragraph provides greater control and better possibilities for detail tagging and compartmentalized analytical searching. Because a detail tag applies to a specific subject (as a written paragraph does, or at least should), you would expect zero-to-one detail tags per paragraph. But this is not necessarily true: a specific paragraph may detail tag to more than one element.

In essence, a detail tag is an XBRL footnote. For each disclosure block, you are creating a footnote to an external element to which the disclosure also pertains. Handled manually, this can be extremely time consuming. In the old days before computer compilers, people would tediously take Fortran code and convert it into assembler. It took a technician to back up a programmer. Similarly, today we have detail tag technicians who manually create footnotes based on detail tagging instructions provided by reporting managers. It does not have to be this way. A good software product should allow you to drag and drop an element onto a disclosure block to create a detail tag. That’s it — no additional effort should be required.

Detail tagging is a difficult process and requires professional proficiency to achieve the quality of cross tagging required. There are over 16,000 elements in the US-GAAP taxonomy. For each text-based data fact, the question arises as to if and how to detail tag. Detail tagging requires human effort and prudence regardless of the best efforts of your software.

Consider the following examples taken from a presentation on detail tagging at the 2009 XBRL US National Conference held in November:

Derivatives
The fair value hedge has a notional amount of $250 million, and hedges approximately 86% of the $292 million of outstanding senior notes maturing in September 2011. The estimated fair value of the contract at September 30, 2009, was $3.5 million.

The possible detail tags may include the following elements:
•    NotationalAmountOfInterestRateFairValueHedgeDerivitives
•    PercentageOfDebtHedgedByInterestRateDerivitives
•    SeniorNotes
•    InterestRateFairValueHedgeAssetAtFairValue

There is obviously a fair amount of skill required by a reporting manager to make the above determination. However, in terms of accountability, there is little the SEC can do to insure the degree of quality required by the above declarations.
 
Income Taxes
The Company recorded a tax provision of $25 million, an effective income tax rate of 10.7%, for the quarter ended June 30, 2009, and recorded a tax provision of $170 million, an effective income tax rate of 40.0%, for the quarter ended June 30, 2008.

Here are the elements we’re dealing with:

The effective tax rate element is a disclosure containing the above paragraph. Income tax expense is a number that will be footnoted using the same paragraph.

The disclosure paragraph will be text blocked. Effective income tax rate and income tax expense will be detail tagged.

Basic Guidelines
Here are some basic guidelines for detail tagging:
•    Only text-based paragraphs can be detail tagged.
•    Abstract elements may not be used as detail tags.
•    A detail tag applies to a data fact. Elements not having associated facts cannot be detail tagged.
•    In most cases, a detail tag applies to a numeric or date type element. A detail tag is a footnote to an existing data fact.

Detail Tag Granularity
An interesting point of discussion is how detail tags appear in instance documents. Of particular interest are detail tagging of disclosures that consist of multiple paragraphs.

Each paragraph may have its own set of detail tags. The question is how this is to be reported within the instance document. The lowest level of granularity provides maximum transparency. This means creating a footnote for each individual paragraph with links only to the detail tags pertaining to that paragraph only. The alternative is to have one footnote for the entire disclosure and then applying all detail tags that apply anywhere within the disclosure.

For example:

In the granular approach, two footnotes are created, one for each paragraph. The first applies to income tax expense/benefit and effective income tax rate only. The second applies to unrecognized tax benefits and the unrecognized tax benefits that would impact the effective tax rate.

Using the general approach, there is only one footnote. The entire disclosure is tagged to all elements applicable to any paragraph within the disclosure.

The granular approach provides more transparency to viewers, since detail tags are isolated to specific paragraphs. The entire disclosure including both paragraphs would be detail tagged to all four detail tag elements as a single footnote. Based on policies of the SEC of items two through four from the list at the beginning of this post, my interpretation is that a lower level of granularity is preferred. This is specifically stated in that each table within each disclosure is to be tagged as a separate block of text and that each numeric fact must be individually detail tagged.

Detail Tag Crawler
Detail tagging is a difficult process. It requires professional proficiency to achieve the quality of cross tagging required in the detail tagging process. There are over 16,000 elements in the US-GAAP. The question arises for each text-based data fact as to if and how to detail tag. A good software product will assist you in making smart choices. An intelligent detail tagging assistant compares your data fact to labels in the taxonomy in order to provide you with a selection of best choices. For each element it arrives at a matching weight of best possibilities to detail tag to. This is not an easy task and one that is not always conclusive. A crawler can match some tags, but not necessarily all that may apply. Let me again emphasize: Detail tagging requires human effort and prudence, regardless of the best of efforts achieved by your software.

Conclusion
The EDGAR Filer Manual (EFM) requirements are considerable. In my posts, I have only touched the surface of the many issues a filing process entails. The process of completing a filing requires two hats: (1) the reporting professional who makes decisions on mappings and when to extend or not to extend elements, and (2) a technician who understands these requirements and can translate them into an XBRL filing.

Regardless of the ease and simplicity of your XBRL software product, there is a learning curve that must be considered before moving filing services in house. Filing agents find this learning curve acceptable, since being able to convert filings to XBRL is a future necessity for filing agents to be able to stay in business. External reporting managers may consider outsourcing.

Written by Peter Boritz     Posted on December 22, 2009

Peter Boritz is the architect and chief technical officer for Snappy Reports XBRL and can be reached via e-mail.

In Part 1 of this four-part post, I offered an overview of the problems associated with XBRL filings; in Part 2, I focused on those associated with the Interactive Financial Report Viewer. This post looks at filing issues in several areas, including taxonomy extensions, negated facts, consistency checks, fact checking, filing path, per share information, and decimals.

Taxonomy Extensions
You should extend for new elements only if there is no existing element within the US-GAAP taxonomy that expresses the concept you are wishing to apply. Your software should give you access to documentation labels. These provide you with the information you need about what an element represents. You do not extend for a new element if there is an element within the US-GAAP taxonomy that expresses the same concept. However, the standard label for an existing element may not match the terminology you use in your filing. In this case, map to the existing element, but create an extended label in your extension whose value displays the element using the terminology in your paper filing.

Negated Facts
Another issue to contend with is the translation of data in a spreadsheet to the taxonomy and the translation of the taxonomy to the Previewer. Negated labels are part of this process. Spreadsheets typically use positive and negative numbers to represent debits and credits. For example, the equity section in the balance sheet within a spreadsheet would show equity facts as positive values minus a subtracted value for treasury stock. Treasury stock has a debit balance. When data facts are moved from a spreadsheet into the filing, the value for treasury stock arrives as a negative value. In actuality, it is a positive debit, so it must be multiplied by minus 1 to make sense out of it. The reverse holds true in the Previewer. It does not recognize offsetting debits and credits. All values in the equity section will be listed as the positive values that they are. Total equity will not properly add up, because it will include a difference of twice the value of treasury stock.

Treasury stock must therefore be negated. This is where you implement a negated label. A negated label is a label category. You set the preferred label in the presentation arc to point to a negated label. This tells the Previewer to multiply the debit value of treasury stock by minus 1 and display it as a negative.

You may be thinking, Why not keep the value for treasury stock as the minus value originally in the spreadsheet? Then you won’t need a negated label. Nice try, but your filing will be wrong. You will have a minus debit which is factually incorrect.

Consistency Checks
Filings must also pass a consistency check. If you map in a value for a calculated element, such as total assets, a consistency check uses the calculation linkbase to verify that the sum total of assets equals the value you mapped to it. If any provided total does not match its corresponding calculated total, an error will be generated.

Fact Checking
A requirement of any filing includes document entity information. This includes information about the company and the documents being filed. Information must be precise and case sensitive. Many questions are of the Yes/No type. These require a simple Yes or No (capital Y or capital N). Other questions (such as amendment flag) are true/false (small t or small f). If you get the case wrong, your filing fails. Your software must also be able to tell you what type of answer is required, and it needs to be able to validate your answers. These are text-based answers that require precision.

Some questions require selection from an enumerated list. This means the answer to a question must match an exact, case-sensitive list of words provided in the taxonomy, such as “large accelerated filer."

Filing Path
A taxonomy imports other taxonomies, which import still other taxonomies. The end result is a complex hierarchy tree. The US-GAAP taxonomy is no different. Its import path is detailed and complex. The US-GAAP taxonomy is rich in is its menu of elements and reports. A good software product will allow you to use all of these as a template for completing your filing. This means your software must path through the entire taxonomy in order to present you with all possible choices.

The SEC limits possible entry points for the US-GAAP taxonomy that can be declared within your filing. These are low level entry points that do not include reports. The process of completing a filing requires two pathways: 1) a complex pathway that provides you access to the complete taxonomy for development purposes and 2) a clearly defined short path that the SEC will accept for filing purposes. Your software product should optimally support both.

Per Share Information
The SEC requires that per share information be defined as USD/shares. This is not defined in the US-GAAP taxonomy. Your filing must include a custom USD/shares type. A good software product will require you to provide basic information pertinent to your filing. It uses this information to convert shares/item type to a custom USD/shares type in your instance. This process should be transparent to you. Minimizing the requirement of XBRL expertise is a key ingredient for any software product.

Decimals
The decimals attribute defines the degree of accuracy for which a value can be considered material. Decimals are expressed as a negative number to the left of the decimal point. A value of -3 indicates thousands, -6 indicates millions. This would be declared as part of your filing information within your software product. Your software should use this information for the purpose of universally declaring the decimals attribute applicable to monetary types. Per share information would have a decimals attribute of +2, meaning accuracy can be relied upon two digits to the right of the decimal.

Written by Peter Boritz     Posted on December 14, 2009

Peter Boritz is the architect and chief technical officer for Snappy Reports XBRL and can be reached via e-mail.

This is the second installment of a four-part series on filing XBRL statements with the SEC; Part 1 provided an overview of XBRL filing issues. 

US-GAAP includes over 90 detailed reports – not only the basic reports of balance sheet, income statement, and cash flow, but also a lengthy list of industry-based reports, including both statement reports for financial facts and text-based reports for disclosures. These provide good guidance in properly completing your XBRL filing.

But US-GAAP reports serve as starting-point templates only. The SEC does not use these reports. You have to create your own reports within your filing. This leaves you with two choices: (1) start with an existing report and distill it down, or (2) start from the beginning and add the elements you want.

Moreover, your filing must be presentable in the Interactive Financial Report Viewer. This is no small task. The Viewer has limitations that you must contend with:

1. The Viewer Does Not Process Calculation Linkbases You must map totals to elements whose values would otherwise be calculated. The Viewer will not process calculations or show elements with their calculated values. These must be handled manually.

2. The Viewer Does Not Process Dimensions The technology of XBRL dimensions implements data warehousing concepts within XBRL. A data warehouse is a database that is designed for query and analysis rather than for transaction processing. A warehouse stores facts of interest and uses lookup tables for quick access. The Viewer does not display data stored in dimensions. Reports such as the Statement of Shareholders Equity are rich in dimensional categories for facts of interest. The Viewer is unable to display the shareholders equity report or any other report that uses dimensions, if dimensional aspects are used in the instance document.

3. The Viewer Cannot Render Complex Reports  It is unable to render the reports provided as part of US-GAAP. These reports are complex and rich in detail.

The Viewer is able to display only a subset of elements. These include only elements having a mapped value and their immediate parent. Elements that are nested deep within the report hierarchy do not display in proper context. For example: the element Cash and Cash Equivalents sits four levels deep within the Statement of Financial Position under the element Restricted Cash. The Viewer will display both these elements, but without groupings for Assets or Current Assets. You will wind up with a balance sheet consisting of unrelated and out-of-context disconnected pieces.

4. The Viewer Does Not Display Footnotes A footnote in this context is not a disclosure. It is an everyday footnote similar to what you may see at the bottom of a Word document. A footnote is used to further describe a data fact in the report.

Here’s an example of the usefulness of footnotes. An element contains a label which provides human readability for spoken languages. There can be only one label for any given language and label category combination. A problem occurs if the label changes from filing to filing. We need a way of keeping both labels. One way of doing this is to have a different extension for each filing. This causes scalability problems and more work. An alternative is not to allow the labels to change from filing to filing. This can be done using footnotes to present variable changes that happen between filings. The labels remain the same, and footnotes are used to present information specific to individual filings.

For example: the label “Property Plant and Equipment net of Accumulated Depreciation” is a static label. Typically, however, a label may more likely resemble “Property Plant and Equipment net of Accumulated Depreciation of $x and $y”. This label is no longer static, because the values of $x and $y are tied to the filing based on data facts within the filing.

Some software products can cross-reference. This means that the footnote will pull the value of an external element (in this case accumulated depreciation) and place it in the footnote. This would be nice to do for a label. It dynamically changes the value for labels from filing to filing without the necessity of cloning extensions and then modifying labels on a filing by filing basis. The use of dynamic labels solves reusability and scalability issues that would otherwise require that extensions be cloned.

These are four limitations of the Viewer. One piece of good news is that the SEC is less concerned about how your filing appears in the Viewer and more concerned about the data in your filing. But the reality is that your clients and peers will look at your filing in the Viewer. The Viewer is the yardstick by which they will measure the quality of your work.
 

Max Mansur is a Global Market Manager in Securities Markets at SWIFT.  He works in the asset servicing domain addressing the needs of custodians, securities market infrastructures, broker/dealers, investment managers, issuers, and their agents. Mr. Mansur has 31 years of information technology experience including system design, program management, quality, and financial solutions. He can be reached by email.

This is the second part of a two-part interview. Part 1 contained questions 1 through 6.

7. Could you describe a bit of the history behind using XBRL for corporate action communications? When was XBRL first considered as a possible solution? How have developments in the XBRL field – such as the SEC mandate and US GAAP taxonomy creation – affected the assessment of XBRL for the corporate action process?

There have been several threads behind looking at XBRL for corporate actions. The problem is long-standing and multinational. It is all driven by “there’s got to be a better way” and “can’t we just get data from the source?” I personally heard the idea of a technology to tag key data within documents in the UK about three years ago. Soon after, I wove it into some presentations I made at Sibos (SWIFT’s annual international conference of financial institutions) and to ECSDA (European Central Securities Depository Association). At the Sibos presentation, DTCC’s CEO, Don Donahue, was in the audience and the first to comment on the approach. I believe the wheels were already turning there. And SIFMA’s Corporate Actions Division had already made unsuccessful overtures to the SEC asking for issuers to provide a cover form of key data for filings under the mergers and acquisition regulation.  

So the need for data from the issuers was well established. David Hands of DTCC had been discussing this in professional groups for the last ten years. The advent of XBRL for SEC filings obviously stimulated interest because the same entities produce corporate actions and, sometimes, even using the same documents. So it was the program, the sponsorship of serious work by XBRL US, the strong leadership of its CEO, Mark Bolgiano, and finally the mandate that created an environment ripe for corporate actions.  

The rest of what we call the “perfect storm” to get the project underway was, unfortunately, the financial crisis. This fueled both the drive for transparency and significant loss of revenue to apply manual effort to address shortfalls in corporate actions processing. The need, plus the right technology, plus the development of ISO 20022 corporate actions messages in XML format, became a foundation when corporate financial reporting in XBRL was mandated.

Underwriting the commitment of SWIFT and DTCC, beyond the formation of the Issuer to Investor: Corporate Actions initiative, both Chris Church, CEO Americas of SWIFT, and Don Donahue, CEO of DTCC, have joined XBRL US as founding members. Also, Jamie Shay, Head of Standards for SWIFT has joined the board of XBRL International.

8. How would the adoption of XBRL for the corporate action process occur on a global basis? Would it be adopted country by country, jurisdiction by jurisdiction? Could the XBRL taxonomy currently being created in conjunction with XBRL US be adopted by other countries in whole? Or would different corporate action taxonomies be needed for different regulatory regimes, which would then need to be harmonized, similar to US GAAP and IFRS?

This is a challenge, but the approach we’ve taken in the US is resonating in many markets. Each market would have some differences, but if we are skillful with maintenance of the core taxonomy as aligned with ISO 20022, then the biggest differences would be entry points based on templates appropriate to the market.  This kind of work goes on already via the Securities Market Practice Group (SMPG) for corporate actions. However, each market and jurisdiction would need to work together to establish the templates and then build out the entry points needed for their country. Given the international vitality of ISO messaging, ongoing work to harmonize market practice, and the discipline being demonstrated within the industry, this is a very achievable goal. The power of the regulators and market infrastructures, since they are charged with protection of investors and market strength, will have an unavoidable role creating the incentive necessary for success.

9. How would the implementation of an XBRL solution to corporate action events proceed? For example, might it first be adopted for relatively simple and data-specific events (like dividend announcements) and then be implemented for more complex, text-heavy events (like M&A activity)? Would it be comparable to the SEC mandate, i.e., implemented in stages with the largest companies going first? Or would it be adopted by all parties for all events in one fell swoop? Do you anticipate the need for an equivalent of the SEC’s Voluntary Filing Program (VFP)?

Good set of questions. For the moment, we don’t know. One factor: how compelling is the business case? Do the desires of the financial institutions processing corporate actions meet well with a roll-out strategy? The SIFMA Corporate Actions Division effort was focused on the most complex as being the highest risk – the situations wherein a mistake can incur major damage through claims. However, these are also the less frequent type of corporate action events compared with dividends and payments which, though simple, cover the lion’s share of all corporate action volume. I would definitely imagine at least a pilot or voluntary program to demonstrate value and work out any bugs since this is the first ISO 20022-based XBRL implementation. The best answer is that the Issuer to Investor team of DTCC, SWIFT, and XBRL US are working with our Stakeholder Group to determine the best way forward.

10. What kinds of government action are required to adopt XBRL for corporate actions? What changes are required in legislation or regulation that must meet SEC approval? Do you believe the regulatory environment is conducive to adopting XBRL?

The discussion is open at this time and pending completion of the business case. The regulatory environment appears conducive. At a minimum, it seems straightforward to require XBRL filing for all current required corporate action disclosure. Adding XBRL to corporate actions announcements that are not required for SEC filing may take more effort, but the result may indeed justify this kind of requirement. Why announce some corporate action event types with XBRL to identify key data, but not the rest of the event types? (By the way, please check out The Asset Managers Forum (AMF) website; AMF is a part of SIFMA and has recommended the Issuers to Investors program for corporate actions to the SEC.)

11. In contrast to the strong and consistent support for XBRL voiced by the prior SEC Commissioner, the current Commissioner Mary Schapiro has been notably less vocal in her support for interactive data. Do you see that as a significant roadblock for implementation?  

I would refer readers to the three-part interview this blog did with Paul Wilkinson in October and November, particularly question 5 in Part 1. Paul very clearly elucidates Mary Shapiro’s challenges as well as those faced by Christopher Cox at the end of his term. And, as widely reported at the XBRL US conference in November 2009, the second mandatory filing revealed significant improvements over the initial 2Q filing in cost, speed, and quality. The term “pleasantly surprised” came from many quarters, including, unofficially, the SEC representatives. With the program launched and moving forward – the proof is in the pudding, they say – success will breed the enthusiasm that the XBRL community would like to see.

12. Maintenance has arisen as a significant issue for XBRL financial reporting (FR) taxonomies. Do you believe maintenance will pose a similar challenge for corporate action taxonomies?

Maintenance is absolutely a significant challenge. How do we avoid a diverging new taxonomy for every market adopting XBRL for Corporate Actions? Luckily, this is an area where ISO and SWIFT have been working together successfully for a long time: global standardization. I am certain that there will be significant opportunities to share in this area. The notion of extensibility is already beginning to be accepted and institutionalized for ISO 20022 messaging, strongly driven by the DTCC, but like XBRL will need a mechanism to manage the extensions and collaboratively fold back into the core standard. It is a must that we implement a global maintenance scheme to ensure corporate actions taxonomies remain aligned with ISO 20022 while the core taxonomy is adopted and adapted for new markets. I won’t speculate on the solution details because this is another area wherein there is significant ongoing discussion, but maintenance must be solved in a professional, efficient manner or risk moving toward entropy.

13. Are you concerned that companies may simply have had enough XBRL with the mandate for financial reporting and do not want to hear any more about it at this time? Or do you sense an eagerness to leverage the XBRL investment that has been made by extending the data standard to new areas like corporate action events?

I don’t know — we haven’t gone far enough yet. Let’s hope it will be old hat and easy to do by the time we show up with a demand, or rather, an opportunity to expand on clarity and efficiency in communicating the financial corporate activities that affect their owners, the shareholders.

Written by Sunir Kapoor    Posted on December 7, 2009

Sunir Kapoor is the President and Chief Executive Officer of UBmatrix. He is also currently serving as a member of the XBRL US board. Sunir previously held executive roles at Oracle, Microsoft, Novell, and a number of Silicon Valley startups.

For all the energy expended today on XBRL document creation by filers, the market tends to focus on data “tagging,” losing focus on XBRL’s other unique aspects. If XBRL were just about tagging or “bar coding” data, many other tagging approaches/technologies/standards in the market would deserve our consideration. What actually sets XBRL apart, though, is the wealth of semantic information that can be associated with tagged data, and the ability this provides to automatically process that information.

XBRL’s distinguishing benefit is that it enables the flow of information that is syntactically correct, complete, accurate, and consistent. This empowers XBRL documents’ creators and consumers to leverage that information to reap the full benefits of XBRL.

Today, let’s focus on one of XBRL’s key features: validation.

Everyone in the reporting information supply chain benefits from the validation enabled by XBRL’s calculations and formulas semantics. XBRL’s validation reduces the number of errors introduced into this reporting process, helping address the classic “Garbage In / Garbage Out” challenge. For example, filers can use XBRL calculations and formulas to validate their filings before submission.

XBRL validations can take various forms. The Calculation Linkbase allows filers to check their XBRL documents for simple math errors. The Formula Linkbase allows the filer to validate their XBRL documents against a set of business rules — and XBRL is extremely powerful in its ability to support a wide range of such rules. Examples include checking whether calculations are within a given tolerance; checking ratios amongst reporting items and raising a flag if the ratio is out of norm; and checking for a valid filing, for example, if concept A is reported, concept B must be reported.

To allow everyone in the information supply chain to clearly understand what defines a valid information exchange, XBRL’s Calculation and Formula Linkbases can be shared between the consumer and creator of XBRL documents. Furthermore, because these business rules live in the taxonomy and are not hardcoded into the applications that either create or consume XBRL documents, it is easy and quick to update business rules and communicate these changes to all parties.

Formulas have already demonstrated value in production systems. While everyone talks about the FFIEC/FDIC as among the first successful large-scale projects, what isn’t often discussed is the key role that XBRL formulas played in its success. The XBRL formulas written by the FDIC have allowed banks to pre-validate their filings before submission, with dramatic top-line results. Submissions with correct math have increased from 70% to 100% of filings. The number of “clean” submissions have increased from 66% to 95%. With respect to the SEC’s XBRL mandate, formulas now can be used to check XBRL filings against the EDGAR Filer Manual. Charlie Hoffman has been using formulas to apply additional validation checks against SEC filings.

A current example that highlights how XBRL validation could improve the reporting information supply chain is in recent news regarding American Recovery and Reinvestment Act (ARRA) stimulus reporting in the United States.

To qualify for stimulus money, recipients are required to fill out detailed federal forms, but with 130,000 recipients and 99 data fields to enter, there’s much room for error. Government Accounting Office analysis of the first round of reports from recipients showed 3,978 reports that “showed no dollar amount received or expended but included more than 50,000 jobs created or retained.” The GAO also found more than 9,000 reports that showed no jobs created or retained for more than $1 billion spent. Reports have circled describing money being spent in non-existent congressional districts.

Simple XBRL formulas could have checked the validity of submissions like these — e.g., checking for a correct congressional district — and flag outliers that need review, such as the ratio of money expended vs. jobs created.

The market needs to figure out how to exploit XBRL’s key benefits — taking advantage of validation, one of its key differentiators. The risk of failing to do so is that XBRL would end up just one among many data exchange technologies, and the information supply change would miss out on sorely needed improvements.

Written by Peter Boritz     Posted on December 3, 2009

Peter Boritz is the architect and chief technical officer for Snappy Reports XBRL and can be reached via e-mail.

This is the first installment of a four-part series on filing XBRL statements with the SEC.
 
The SEC has adopted interactive data for financial reporting, and the largest US companies began submitting XBRL statements this year. But creating XBRL filings that pass muster with the SEC can be a complex process. Despite the best of intentions and the easiest to use XBRL software, the road to filing can be bumpier than expected. A filing:

• Must be complete and accurate
• Must include both disclosures and financial data and possibly be detail tagged
• Be syntactically XBRL correct
• Pass a consistency check
• Pass best practices verification
• Be properly mapped from an accounting perspective
• Be quality controlled. The contents of XBRL documents must be viewed and compared against paper filings for completeness and accuracy.
• Be presentable in the Interactive Financial Report Viewer
• Include all required document entity information in its proper format
• Include report templates for public viewing
• Include proper import, namespace, and decimal declarations
• Optimally, be able to provide an audit trail of who did what and when and why for internal audit and SOX compliance

Filings can be managed in-house or outsourced. In-house provides you with more security and control, but it requires staff time and training. Although outsourcing makes life easier, you still share the responsibility of working with your provider to be sure your filing is complete and accurate.

Guidance for filings is designated by the EDGAR Filer Manual (EFM) published by the SEC, which elaborates in great deal the requirements of a proper filing. Preparing an XBRL filing requires a combination of professional reporting skills and XBRL technical skills. A good software product should keep the XBRL technical skill requirements to a minimum.

A comment was once made to me that XBRL clients do not want to think. I’m sorry. Thinking is a requirement for any XBRL filing. Careful consideration must be made not only to the mapping, but also the general layout of the filing and when to extend elements. And being able to complete a filing and pass an XBRL syntax check puts you only at the beginning of the starting line. Your filing will be checked for best practices and may be rejected if it’s not.

Notably, the SEC requires that your XBRL presentation be as close to identical to your paper filing as possible. Your filing must be displayable — proper presentation is important. In my next post, I’ll discuss making your data displayable in the SEC’s Interactive Financial Report Viewer.  

Written by Bob Schneider    Posted on December 3, 2009

Auditors must not only be independent but be perceived independent as well. The rules for book reviewers should be no less stringent. Finding critics who have background in the field but no skin in the game, however, is a daunting challenge — even for the biggest publishing institutions.

With these considerations in mind, I wrestled with writing a review of the new XBRL for Dummies by Charlie Hoffman and Liv Watson. That Charlie has always been a good friend of this blog, and that Hitachi XBRL products are mentioned in the book (among many others), could be dealt with through mere disclosure. Because Hitachi created a book with the same name, though, I worried readers would understandably wonder, “where’s he coming from?”, regardless of what I wrote.

That’s why, initially, I thought I’d merely tweet the July post that sought to distinguish the two XBRL for Dummies books and leave it at that. Having now read Hoffman & Watson’s book, however, I think it would be a disservice not to discuss it.

There are so many things I like about this book. Often while reading it, I found myself observing, We should have done a post on that, and I should have suggested to so-and-so to write about that. Hoffman & Watson strike a deft balance between providing readers with a comprehensive-but-not-overly-technical explanation of XBRL and discussing how the standard affects their business lives, and thus why they need to know about it. The book doesn’t overwhelm with an extended technical explanation of XBRL in one barrage. Rather, it gradually introduces knowledge of the standard, so that at each point the reader feels informed to appreciate the authors’ larger points about why XBRL is important to the exchange of business information.

Throughout, the book greatly benefits from all the work Hoffman has done in recent years to make XBRL understandable to business professionals, and a truly massive number of Web links he has assembled for references.

Here are some parts I especially appreciated:

Syntax Is Not Enough (pp. 41-47)

Hoffman & Watson pointedly emphasize that XBRL is information structured for meaning — not merely for presentation. They pithily state, “There’s a big difference between <bold>1000</bold> and <Sales>1000</Sales>” [emphasis added].

Recent articles in the business press often referred to XBRL as “tagged data,” but the discussion reminded me of how inadequate, even misleading, this description can be. Perhaps we can rechristen XBRL as meaningful business information, or MBI? (At the least, it would provide a playful title for a post about the use of XBRL for mortgage-backed securities: “MBS Require MBI — Even an MBA Knows Why”…)

Explaining XBRL at the Water Cooler (49-52)

Hoffman & Watson realize that a primary motivator for buying their book will be, My boss just asked me what XBRL is — what do I tell him? In addition to providing an XBRL-in-a-nutshell explanation, the book offers (extensive) suggestions for having follow-up conversations with anyone who casually asks you to explain the standard.

Creating and Using XBRL (Chapter 15)

I like it when a book about a technical subject gets the reader directly involved with hands-on examples. An entire chapter provides readers with step-by-step exercises to view XBRL taxonomies and instances — small ones that Charlie did himself, as well as large, external ones — and import XBRL data to Excel. (I didn’t have success in downloading the SpiderMonkey software required to do some of the exercises; but that may be because of factors peculiar to me.)

Differentiating XBRL Modules (Chapter 16)

XBRL is a family of specifications with modules for dimensions, formulas, rendering, versioning, and generic linkbase. While this unity may be obvious to practitioners, I don’t think it is fully appreciated by more general observers, who may just see the string of apparently unrelated announcements that have been issued on each specification. Chapter 16 gives the reader a sense of what the whole of XBRL entails.

Looking at XBRL Taxonomies and Instances (308-312, 333-338)

Often, when exposed to new computer areas, the novice asks, “What am I looking at? Is this the same thing I just saw presented differently, or something else entirely?” Hoffman & Watson easily could have dismissed this concern in two sentences, but they opt to present taxonomies and instances as they appear in the physical files, viewers, printouts, etc., to expose the reader to the various ways that content will appear.

A Thought Experiment (330-33)

An extremely interesting exercise discusses some of the difficulties involved in using XBRL data. In the example, the objective is to find a good investment on a worldwide basis. Hoffman & Watson describe all the challenges that await the user, from finding the instances to creating the analysis interface. This exercise well demonstrates the gap between what is technically possible and politically achievable.

Identifying a Good XBRL Taxonomy and Instance (321-323, 343-346)

What struck with me was how many of Hoffman & Watson’s recommendations — no duplication, consistency, documentation, maintenance, adequate testing, and, not least, elegance — are the same as those for developing a great database. That comes as no surprise to the authors: they note the similarity, too.

Specific Uses for XBRL (353-355)

This is the authors’ wish list of what software applications will be capable of accomplishing by making use of XBRL. One potential that Hoffman has emphasized but that still remains under-appreciated is an automated disclosure checklist: basically a set of business rules that can ensure that financial statements are properly created.

Keys to Understanding How XBRL Works (369-376)

A good review of some of the book’s main points, nicely summarized.

Isn’t there anything to criticize? There always is.

On the “what’s missing?” front, there’s little about how XBRL got started. In contrast, XBRL for Interactive Data by Debreceny et al. contains a long introductory letter on XBRL’s beginnings by Hoffman, and the AICPA has published an online history.

I also don’t remember seeing much about XBRL vis-à-vis assurance or auditing, and the absence of these terms in the index would seem to confirm my recollection.

Turning to “what didn’t I like?,” I didn’t find the substantial discussion of networks in Chapter 4 and elsewhere to be helpful to my understanding of XBRL. Networks is one of those MEGO words (like systems) that’s difficult to get your arms around, and I couldn’t do so here.

As well, having made the decision not to write a book primarily for IT people, I could have done without the concluding chapter of technical “odds and ends.” Reference books are rarely read cover to cover, but this chapter of technical tidbits may leave the average reader feeling that he doesn’t really know XBRL after all, despite having just read the book.

These are quibbles, though. Hoffman and Watson’s XBRL for Dummies not only teaches XBRL but gives the reader a strong understanding of the issues involved in business information exchange.

It is a major achievement. Buy the book.
 

Max Mansur is a Global Market Manager in Securities Markets at SWIFT.  He works in the asset servicing domain addressing the needs of custodians, securities market infrastructures, broker/dealers, investment managers, issuers, and their agents. Mr. Mansur has 31 years of information technology experience including system design, program management, quality, and financial solutions. He can be reached by email.

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

1. In your capacity as a senior manager at SWIFT, you are working with the DTCC and XBRL US "to fundamentally change corporate actions announcement processing" by integrating XBRL into the system. To begin with, could you explain what corporate actions are and what activities they entail?

A corporate action is any activity that impacts a security that has been traded, cleared, and settled on behalf of the investor. Typically initiated by the public company issuing an equity or offering a bond, the action needs to be described and communicated to all investors and holders of the security as well as the public. The announcement of the action can include dates, rates, periods, prices, options, conditions, terms, exclusions, identifiers, and other characteristics. So there’s a lot of data that is often wrapped deeply in legal verbiage to prevent or mitigate any potential litigation for the action. The more complex the action, the longer the document will be, often into hundreds of pages.

The tradition and even regulatory mandate is all paper-oriented, hence the interest in XBRL to identify unambiguously the embedded data in accordance with a widely used standard. There are more than 50 types of events that are considered a corporate action including dividends, interest payments, name changes, splits, tenders, mergers, redemptions, calls, spinoffs, warrants, exchanges, Dutch auctions, bonuses, repurchases/bids, and bankruptcy notices. Globally, about one million corporate actions are “announced” each year, 400,000 in the U.S. There are several times as many “scheduled” corporate actions for fixed income securities with periodic distribution of payments, but these are very straightforward so not the focus of our initiative.

2. The data standard ISO 20022 is already in widespread use for corporate action events announcements. Why is an additional data standard like XBRL needed?

First, as an aside, let me say that ISO 20022 is not yet in widespread use for corporate actions; rather, ISO 15022 is the core securities standard that is currently being used by the SWIFT community. However, ISO 20022 was developed to be easily translatable with ISO 15022 to help support a period during which both standards will coexist. As such, we’re avoiding a ‘big bang’ approach to the migration of a few thousand global institutions using ISO 15022 to XML-based ISO 20022. As these institutions asynchronously obtain funding and transition their messaging technology to XML, they can expect to either translate or interface with translated messages for a period of time. SWIFT is preparing support for this transition in consultation with our members and will address other message domains as well, such as clearing and settlement messages.

Now, to your question: First, it is important to understand that XBRL corporate reporting taxonomies are inherited from underlying GAAP or IFRS accounting standards. XBRL doesn’t attempt to create accounting standards; rather, through the design and linkbases of XBRL, it enables the use of existing standards for extensible data reporting that enhance and add value to the human readable form of business reporting. So the XBRL taxonomy for corporate actions doesn’t start from scratch; it begins with the ISO 20022 standard and, by design, will maintain through the label linkbase and style sheets the alignment with ISO 20022. The growth of COTS (commercial off-the-shelf) software tools for XBRL, facilitating a marriage between “paper” and “data,” is the value that XBRL brings to the table beyond ISO 20022.  

The genesis of ISO financial messaging has been the enabling of standard business workflows between financial institutions based on a common business model and data dictionary. ISO 20022 is emerging for corporate actions, and will be live in late 2010, built on the very solid basis of ISO 15022, a tag-value messaging standard that was widely adopted in the early 2000s for securities, currently with several millions of messages processed globally each month. Another several million corporate actions messages per month are not ISO, but proprietary within several markets, including the U.S.’s DTCC messages. The advent of ISO 20022 means, with XML and a more robust business definition basis, that virtually all markets globally are committed to the new standard. DTCC will begin with corporate actions announcements in 2010. This is a large part of the opportunity to concurrently roll out a corporate actions taxonomy aligned with ISO 20022 in 2010 and reap the rewards of clean data from the source using the most advanced standard available.

3. So ISO 20022 will be the basis for the XBRL data elements, structures, and validation in the corporate actions taxonomy?    

Yes, that’s right. Additionally, market practice guidelines help define entry points in the taxonomy, making tagging eminently more usable by the issuers and their agents. I think this compares favorably with the way US GAAP governs the financial reporting taxonomies where XBRL only expresses data elements that are meaningful from a GAAP viewpoint while implementing entry points that are useful by the reporting industry, such as energy or airline manufacturing. Interestingly enough, we expect fewer than 500 data elements for corporate actions whereas US GAAP currently exceeds 17,000 data elements.

4. Could you describe the "scrubbing" process that corporate action announcements now undergo? How will XBRL remove the problems associated with it?

Good, now we’re at the heart of the matter. Many different institutions have the responsibility of monitoring securities for announcements of corporate actions. Upon discovering an action announced for a held security, a custodian gathers feeds from multiple sources, each of which has attempted to send the correct data in a message. The core problem is that each source manually entered the data by reading and interpreting the source document. This is a recipe for discrepancy, thus scrubbing is necessary to create the “golden copy” which is really just the best version of the truth based on all these indirect feeds.

If the issuer or their agent tagged all the key elements of data and attached an XBRL file to the filing, press release, or prospectus with which they currently announce to the market, then there could not be any discrepancy because there would be data from the source. The additional information that a financial institution, like a custodian, adds to the message is all specific to the institution’s accounting and servicing of the holdings related to the event, not the event itself.

One important aspect to remember is that a complex corporate action event may take several months to complete from start to finish, with many documents filed and many updates. Each update is repeatedly going through the “scrubbing” process without core data from the source. This is the source of tremendous risk, as well as all the additional time necessary to manually check, rekey, validate, and try to prevent a costly error that could be in the millions of dollars.

[Editor's Note: The Corporate Actions 2009 backgrounder is an excellent resource for more in-depth discussion of these topics.]

5. Slide 7 of the corporate action presentation you made in July to the XBRL technology workshop held in Santa Clara states that "Institutional investors often use multiple custodians with the potential for conflict in the custodians’ descriptions of the corporate action." How will XBRL help to overcome this challenge?

This is a very deep problem and not easy to explain. The best analogy is a variant of the “telephone” or “whispers” game, except beyond the single chain of a game, it begins with the same complex information from not one, but many origins and then, through several daisy chains, the messages are concentrated into the investment manager. The unavoidable misinterpretation drives errors, thus the need to “scrub” to figure out which of the conflicting data is correct, requiring significant time and introducing risk. So the proposed solution is that, instead of a “whisper,” we’re asking for a standardized “form” of the data instance to be given once from origin of the message. If each custodian and data provider and broker/dealer starts with the same data, with standard-driven precision, at the same time (via XBRL) then how much risk remains?

6. Why is XBRL particularly useful for the technology needs of corporate action announcements? What other technology solutions were considered and rejected? Why is XBRL superior to these alternatives?

XBRL is tailor made for “pointing out” the data of interest within a report. It has huge technical and business momentum. The data can be identified without disturbing the conditional and legal necessities wrapping the data in human readable reports. The issuers are already being enabled to use this technology, so adding a bit more seems achievable for a great deal of investor value. There are tools to help with tagging and reading/rendering. The only other options might be (a) messaging from agents using the ISO 20022 Issuer Agent Corporate Actions messages that Euroclear is deploying for communications between registrars and their depositories, (b) some kind of paper form, or (c) re-inventing some kind of tagging interface to build into or around the ISO 20022 messaging. Corporate actions announcements are business reports for public availability and investor consumption, like corporate reporting. So XBRL is a neat solution.

Written by Chie Mitsui     Posted on November 22, 2009

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.

XBRL Japan held a workshop in February on "How to Use XBRL for Analysis," which I discussed in an interview with this blog. The attendees — analysts, data intermediaries, and representatives of  securities firms — focused on how users can analyze statements using the XBRLized earnings digests that the Tokyo Stock Exchange has been providing on the Web since last year.

Besides showing the audience on how to use XBRL for analysis, the seminar also served to extend the dialogue regarding continuous improvement of the data standard. In order to serve users better, I believe we need (a) more testing from users’ perspectives, and (b) greater opportunity for them to express their views.

Toward that end, we hosted a second seminar with the same theme in September. This time we treated US and Japanese XBRL data together for comparing companies’ performance across the two jurisdictions. Enabling fast, inexpensive, and user-friendly comparisons of this kind should be one of the main objectives of XBRL. 

The important lesson we learned from this exercise is that there are considerable challenges to selecting meaningful sets of elements from among XBRL data. When we asked users to choose several elements (accounts receivable, revenue, etc.) to compare the financial performance of Japanese and US companies, they found the exercise difficult and confusing.

There were two main problems:

Differences in the style of element names    Elements are developed under different business cultures and accounting traditions in different countries, leading to difficulties in identifying elements that can be meaningfully compared.

Differences in the structure of taxonomy    Even if the element names are different, if the structure of the taxonomy is similar, then selecting the correct element wouldn’t be much of a problem. But the different approaches to naming elements, the similarities among them,  and their vast number – US GAAP  taxonomies have more than 15,000 elements — created confusion for participants. In the end, the XBRL tools we employed couldn’t enable the user to select the correct set of elements and contexts.

We used computation of the receivables turnover ratio (sales/account receivable)  as an example. When selecting sales from Japanese financial statements, users just choose the element “NetSales” from the “IncomeStatement”  and the “Current year” period context. All Japanese companies’ taxonomies have the same name for this element, hence users can easily select it.

However, naming for US XBRL financial statements varies. Each company decides its own names for elements, presentation links, and contexts. For users unfamiliar with US company financials, such inconsistent naming causes confusion during the selection of elements for comparison. Because Japanese users are used to a consistent naming style, they have considerable difficulty in selecting elements from US taxonomies. (Japanese taxonomies also have their problems, as I described in the interview.)

At the workshop, we discussed how feedback from users opinions could successfully be channeled to taxonomy makers. In my view, XBRL Japan should lead this effort. The XBRL groups in Japan and the US, as well as the IASB and other teams around the world, should work together to formulate international standards and rules for taxonomy design.

We hope to continue the dialogue on how XBRL taxonomies should be created from the perspectives of international users. Our next seminar will focus on comparisons between IFRS and Japanese XBRL, and I look forward to discussing the results of the meeting.

Paul Wilkinson is Chief Strategy Officer of CLOUD, Inc., the Consortium for Local Ownership and Use of Data. He was Senior Adviser to SEC Chairman Christopher Cox from 2005 until 2009, where he oversaw XBRL adoption. From 2001 to 2005 he was Executive Director of the U.S. House of Representatives Majority Policy Committee, handling international and economic policy. He can be reached by email.

This is the third installment of a three-part interview. Part 1 contained questions 1 through 5, and Part 2 has questions 6 through 10.

11.  How has the financial crisis of the past two years or so changed the playing field for XBRL implementations? With the immediate sense of financial meltdown now passed, has the urgency to adopt XBRL in such areas as TARP funding and stimulus spending diminished?

The crisis has made the case for transparency stronger than ever, for industry and government alike. In industry, better data is obviously critical to detect risk sooner and pierce bubbles earlier. In government, there’s an interesting right-left coalition for transparency and open government. About the time Web 2.0 came around, I began contemplating the chances technology might support a genuine political realignment. I don’t think there’s any doubt that a generation raised using standard communication platforms like Facebook will want to revolutionize the snail-mail era corporate proxy rules, not to mention have better oversight and control over how their tax dollars are being used by their government.

With U.S. fiscal and monetary health in such a precarious position, I think it’s becoming more urgent every day to find ways to use technology to empower government to do more with less. Congress and political appointees tend to assume cost savings necessary to fund political priorities will materialize out of thin air, while career civil servants are left to clean up the messes after each new wave of spending. I hope the people who have dedicated their lives to federal service, rather than politics, will recognize the need for better data systems to improve efficiency and consider how XBRL has proven itself as a flexible financial standard that could be applied as easily to government finances as it was to corporate finances.

12.  In a Comment on a Seeking Alpha article on FAS 157, you wrote that “What the [SEC] staff means by ‘the complete integration of interactive data as a tool to bridge the gap between historical cost measures and fair value’ is using XBRL to give investors choice in how to evaluate asset value.” Could you explain how XBRL enables investors to do that?

Data tagging makes it easier for issuers and financial statement users alike to calculate, disclose, and compare various facts that comprise “valuation.” Some believe anything but historical cost or real market prices are subject to manipulation. Others believe models are the only way to calculate useful valuations in the absence of a market transaction. Disagreements like those are what make markets. And the more information market participants have, the less likely they are to walk away from a transaction on the grounds of uncertainty about risk.

I’ve never understood why ABS couldn’t simply be priced based on anticipated net present values of future cash flows under various scenarios minus risk premiums. Markets value more complex instruments, from currencies to options to public company securities, 24/7/365. During the crisis, the problem seemed to be that ABS holders thought risk premiums were too high and that accepting them would threaten their solvency. Bankruptcy judges work out problems like that all the time, but because ABS and their derivatives were deemed too complex, bankruptcy judges were deemed incapable of handling problems like Bear Stearns. Preparing ABS and derivatives using an industry standard computer language like XBRL could make such securities less complex, meaning bankruptcy judges could go back to doing their jobs. They, like investors, would have more information upon which to base important decisions.

Computers can handle more XBRL data more quickly and less expensively because with XBRL, computers have more data and require less human intervention. The typical fear, uncertainty, and doubt concern the expense of creating systems to produce and analyze XBRL data. But in the long run, the context XBRL data carries, and the software that creates, validates, and analyzes XBRL data more efficiently than data in other forms, saves untold hours of human labor that are typically required to process data in less structured forms.

Computers don’t care if they’re dealing with ASCII text that carries HTML tags or ASCII text that carries XBRL tags. Users, however, when they see the value added by XBRL tags, do care. And users don’t even need to know what XBRL is to see that value. XBRL is the global standard for financial data in the private and public sectors for the simple reason that it’s more efficient than other standards.

13.  In a Comment to a post on this blog, you wrote “A focus on human auditing of XBRL DOCUMENTS could, indeed, be expensive. That’s why machine auditing of XBRL DATA is important.” Could you explain what you mean by that? What is the difference between auditing documents and auditing the data in them?

Presenting XBRL statements doesn’t change most of the audit process. The main new requirement is that the numbers and captions on the old paper financials match the numbers and captions in the new data financials. I try not to use the term “XBRL documents,” since it’s almost an oxymoron. Sure, you can print out the raw ASCII with all the brackets (which would result in really big audit costs since those “documents” are so tough to read), or you can print out numbers from any number of viewers on your PC. But XBRL isn’t intended to be used on its own to create documents. It is intended to let data users and computer programs know what the data means so they can do things with the data that users consider valuable. The point of my comment was to note that besides supporting the rendering of financial statements, XBRL can be used in internal systems, along with other software, to prevent manipulation or unauthorized access. From trusted time stamping to reliable audit trails to cross checking among various systems, handling financial information in data format instead of document format or spreadsheet format promises better audit efficiency and therefore more reliability.

14.  XBRL adoption for financial reporting has been touted as a way to decrease the cost of capital for small- and mid-size companies. Do you think that is likely to happen? If so, why haven’t smaller companies been more vocal in demanding implementation?

Smaller companies are necessarily more concerned about dealing with the world as it is and usually don’t have time to explain to policy makers how the world should be. Future business strategy and innovation are often more important to investors in smaller companies than past financial performance. To the extent XBRL permits funders to get more comfortable with more data sooner, it will reduce capital costs. And to the extent XBRL can be expanded to cover reporting about strategy and innovation, it will also mean more and better competition for capital among smaller firms.

One benefit of the XBRL phase-in will be that big firms will pay the bulk of the costs for the development of software that smaller firms will then be able to use to improve their own financial reporting. Just as HTML and XML standards have empowered smaller start-ups ranging from Google to Expedia to Pandora to take on large old-economy market leaders, XBRL should give smaller companies fairer access to more capital sources. Better information means markets are better able to allocate capital toward better uses – and if small companies can find better uses for capital, they can use XBRL as a tool to help them compete with more established companies. Small companies might overcome large company reputational advantages by using actual authenticated information to compensate for their own less robust reputations.

15.  There’s been much discussion of using XBRL for Enhanced Business Reporting (EBR), Key Performance Indicators (KPIs), and more extensive narrative reporting. How do you view the potential for XBRL in these areas? How important do you think these implementations are compared with those for current financial reporting requirements?
 
With more market participants having more and better access to financial information, that means there will be less opportunity to differentiate your analysis of a particular company on the basis of the financial statements. The market will price in financial information sooner and more accurately than ever. Therefore, non-financial metrics will be more important than ever.

XBRL’s potential in these areas is vast. Whether and when it will be realized is another question of leadership. We have the world’s most powerful capital markets because we have the world’s most powerful information infrastructure, but there are no guarantees for perpetuity. The more we can do to improve the information infrastructure, the better. I’m sure that market leadership to improve the entire commercial and personal information infrastructure will emerge. The sooner it does, the better off we’ll all find ourselves.

Paul Wilkinson is Chief Strategy Officer of CLOUD, Inc., the Consortium for Local Ownership and Use of Data. He was Senior Adviser to SEC Chairman Christopher Cox from 2005 until 2009, where he oversaw XBRL adoption. From 2001 to 2005 he was Executive Director of the U.S. House of Representatives Majority Policy Committee, handling international and economic policy. He can be reached by email.

This is the second installment of a three-part interview. The first part contains questions 1 through 5; Part 3 has questions 11 to 15.

6.  XBRL has not captured the imagination of security analysts and other investment professionals as some had hoped. Why do you think investors have been relatively indifferent about interactive data? As the SEC’s XBRL adoption expands to more companies, do you see that situation changing?

XBRL shouldn’t capture the imagination of analysts, investment professionals, and investors. XBRL isn’t what’s important to them; the data is. Many investors don’t realize it, but they’ve been using XBRL or similar standards for years. The difference is that in the past, third parties have been standardizing and tagging company data, not the companies themselves. The main thing that changed with the public company XBRL mandate is that companies are now responsible for making sure that the data investors actually use is accurate. Companies spend so much money making sure their disclosures are as accurate and complete as possible that it would have been a shame to continue to let all that hard work be subject to third party interpretation, normalization, and potential over-simplification. We’ve all seen what happens in a game of “telephone.” There’s a reason hearsay is inadmissible in court. It may not “capture the imagination,” but eliminating an entire level of hearsay in the world’s leading capital markets has the potential to be a pretty big deal.

What I see changing isn’t necessarily respect for the data standard among non-technical users, although like all successful data standards, the standard must become more useful over time to avoid becoming obsolete. What I see changing is respect for the professionals responsible for preparing the data. Until I became involved in the XBRL project, I didn’t understand the full extent to which the accounting profession is vital to healthy markets. You can see that in the fact that while accountants and auditors were using SOX to improve public company reporting, financial engineers were working to avoid accountants by relying on non-GAAP models for ABS. With XBRL, the accounting profession’s work is transmitted more accurately and more fully to more people who can make more effective use of that work. I suspect that’s one reason the AICPA was such a strong supporter of XBRL from the outset.

7.  In a recent blog, you posited the idea that “NIEM is to XBRL as United States customary units are to the Metric System.” Could you expand on that idea and explain more fully how you see the relative contribution of NIEM and XBRL in implementing data standards for Federal government activities?

The main point I hope readers took from my post is that global standards are more efficient than national standards. NIEM is a domestic U.S. standard. Yet we live in a global economy. It’s just a no-brainer to me that when local standards and global standards are both available, you go with the global standard unless there’s a compelling reason for parochialism. That’s why the G-20 leadership supports global accounting standards. Heck, we almost lost Winston Churchill before WWII because he was accustomed to a parochial standard and looked the wrong way when crossing Fifth Avenue in New York City. Who knows how much we’ve lost as a result of parochial standards?

With respect to NIEM, why should one nation’s government care if its information standards are compatible with other governments’ standards? Well, two reasons are terrorism and financial crime. They’re both global challenges. At the SEC and at the House Homeland Security Committee before that, some of our greatest challenges were facilitating international cooperation among law enforcement and intelligence agencies to combat terrorism and financial crime.

Making NIEM global, through collaboration with XBRL standards, could significantly improve how law enforcement officials work with each other across borders. XBRL’s validation capability could also be helpful in the law enforcement domain. With all the smart people working on both standards, there’s no reason they can’t become fully interoperable open standards – or unified into a single standard. I don’t think anyone knows how NIEM and XBRL will ultimately work together, but that’s what makes working on data standards interesting – someone will always find better ways to make standards work.

8.  In a post describing health information technology standards, you suggest that the SEC’s adoption of XBRL could be used as a model for adopting standards in other industries. In this respect, what elements of the SEC implementation do you find worthy of emulation?

The same leadership gap exists with respect to medical records that existed before the SEC moved forward with XBRL. No perfect standard exists in any domain. After the SEC chose XBRL, much hard work remained to make it capable of supporting high quality GAAP reporting. In medicine, the plethora of incompatible proprietary standards is much worse than in financial reporting. Nevertheless, if patients are to enjoy the benefits of medical records created, transmitted, and used according to open industry standards, someone must overcome the proprietary interests and provide the leadership to choose and develop an open and effective high-quality standard.

In learning, grades can mean different things to different schools and different people. Unique students are taught in identical ways on agricultural calendars in the information age. Someone someday will develop open standards to support a system in which unique students enjoy custom lessons to meet their educational needs and measure their progress. Extensibility, dimensions, presentation layers and more could be big parts of such a standard.

In the end, recognizing the unique worth of every individual – in education, medicine, business, and every sector – requires robust methods to assemble, store, and use complex information. XBRL blazed the trail. I’ve frequently noted that if we could find a way to convert U.S. GAAP to a computer language – when no one is even sure how many tens of thousands of pages of literature comprise the standard – other challenges must be easy in comparison. Other industries have enormous amounts to learn from the XBRL experience.

[Disclosure: I’m the Chief Strategy Officer for CLOUD, Inc., the Consortium for Local Ownership and Use of Data, a new non-profit organization exploring the potential of cross-industry data standards for personal information that would give individual users more control over their own information.]

9.  In a post on your blog about a bill to make XBRL the data standard for disclosure to the US government, you wrote “Bringing labor-saving technology to banking and securities regulation is one thing, but making L.A.’s [legislative assistants] on the Hill redundant? What hath sunlight wrought?” Isn’t it possible, however, that XBRL will increase the demand for analysts, because analysis will be easier to do?

As a former L.A., I certainly hope XBRL makes analysis easier and boosts demand! Perhaps I was a bit facetious. The title of Clay Shirky’s book, “Here Comes Everybody,” says a lot. The nice thing about democracy is that we all have something to contribute, and the more high quality information we have – Chris Anderson’s “long tail” of information – the more we can contribute and the less time we waste sorting information that’s not useful. Too often, the toughest part of quality analysis is collecting the data to analyze. Making data available to the world by supporting open standards and open software to analyze that data can’t help but support smarter decisions.

Freerisk.org and Wikinvest are just two examples of how more accessible data can make analysis faster and better, if not easier. Having faster and better data supports deeper thinking about how to analyze the data. And thinking is hard – so I’m not so sure about “easier.” But by reducing the cost of analysis, XBRL pushes the supply curve of analysis to the right – meaning it intersects the demand curve at a point where there’s more analysis in the market at a lower price. By increasing the quality of analysis – less garbage in means less garbage out – the markets subject to analysis should work more efficiently, resulting in more capital being allocated to more productive uses – a virtuous circle.

10.    What XBRL developments in other countries do you find noteworthy, and what can the US learn from them?

What I find most noteworthy are the many and flexible uses for XBRL. The greatest lesson the U.S. might learn could be, “XBRL – it’s not just for GAAP anymore.” Australia’s Standard Business Reporting project is impressive, as is the work to standardize corporate actions XBRL US is doing with the International Organization for Standardization (ISO), the Society for Worldwide Interbank Financial Telecommunication (SWIFT), and the Depository Trust & Clearing Corporation (DTCC). Using XBRL for corporate actions on a global basis could be like moving from vinyl records to mp3’s. By cutting overhead costs – time costs and money costs – equity financing has the potential to make gains relative to debt financing. And that means stronger and more efficient global capital markets.

Moreover, smoother global accounting, as the International Financial Reporting Standards taxonomy continues to improve, smoother global trading, and a more standardized corporate actions process all mean that more capital can be allocated to its highest and best uses more quickly. More open and competitive global capital markets simply mean that billions of people will be better off.
 

Paul Wilkinson is Chief Strategy Officer of CLOUD, Inc., the Consortium for Local Ownership and Use of Data. He was Senior Adviser to SEC Chairman Christopher Cox from 2005 until 2009, where he oversaw XBRL adoption. From 2001 to 2005 he was Executive Director of the U.S. House of Representatives Majority Policy Committee, handling international and economic policy. He can be reached by email.

This is the first installment of a three-part interview. Part 2 has questions 6 to 10, and Part 3 includes questions 11 through 15.

1. You recently discussed the role XBRL can play in helping to restore the asset-backed securities (ABS) market. Could you explain what benefits XBRL would bring that ASCII and HTML documents do not?

That’s a timely question. The most important near-term benefit would be exploiting XBRL’s off-the-shelf capability to support effective disclosure standardization for ABS. Longer term, I think the “faster, better, cheaper” advantages that SEC Chief Accountant Don Nicolaisen foresaw in the GAAP arena would apply in the ABS arena, as would XBRL’s disclosure maintenance capability.

With respect to the implementation process, it’s true that regulators or an industry consortium could sit down and choose standard ASCII or HTML or Excel column headings or row labels for most of the important information about ABS. In fact, they tried to do so in the run-up to the crisis, but it was a slow process and has yet to result in a fair and efficient market for ABS.

On the other hand, the open process of creating XBRL financial taxonomies in the U.S. proved extraordinarily effective. Once the technical process was underway, I was astonished by the speed, quality, and openness of the XBRL US project. White House adviser Beth Noveck wrote a book called Wiki Government about crowd sourcing patent application research. Well, the effectiveness with which XBRL US crowd sourced the GAAP taxonomy deserves its own book. Your recent interview with the CEO of XBRL Australia reflects my experience in the U.S.: The technology was simple; the politics were the complex part. We couldn’t crowd source the SEC implementation rule, but XBRL US transcended all of the typical politics associated with U.S. GAAP by crowd sourcing the taxonomy.

In addition to the process advantages, there are, of course, myriad technical reasons XBRL is superior to ASCII, HTML, Excel, or any other open or proprietary standard. Extensibility is a big advantage, as is the ability to observe the use of extensions and to create and update standard tags over time – without requiring users to buy new software.

As we’ve seen with ABS, keeping disclosure regulation up-to-date with financial innovation is critical. Over the past decade, one reason capital flowed disproportionately to ABS relative to public companies is because regulators used proven manual systems to keep GAAP up to date. SOX was expensive. It helped prevent more Enron’s and WorldCom’s, but at the same time, it drove capital toward non-GAAP investments. Despite Reg. AB, which was generally a codification of many years of asset-backed securitization legal practice, ABS financial practices continued to evolve, contributing to both the housing bubble and to the growth of multi-layered complex securities on top of basic ABS.

Non-standard ABS reporting made it difficult to see the real risk presented by ABS and by derivatives built on top of ABS. ABS, because they didn’t create human drama or present business strategy questions like public companies do, got less attention than their valuations might have merited were the information available in a larger, more transparent, more liquid market. XBRL won’t bring the excitement of boardroom fights, hostile takeovers, or new consumer products to ABS. But to the extent XBRL for ABS helps investors understand basic facts about the instruments they’re being offered, it’s analogous to GAAP for public companies.

Thanks to computers – and thanks to the fact that ABS are considerably less complex than public companies – technology that took decades to develop for GAAP is already available for ABS. The SEC has plenty of authority to mandate disclosure for securities, which are simply investments of money in common enterprise for profit derived from the efforts of others. The questions are how fast regulators can understand XBRL’s capabilities to enhance transparency and how the SEC can navigate the regulatory minefield set by those whose oxen would be gored by transparency.

2.  Part of your work at the SEC was to help mandate the use of XBRL for public companies, mutual funds, and credit ratings agencies. Are you convinced that XBRL implementations at the national level will always require mandates? Or do you see a path for voluntary adoption to be successful?

The "chicken and egg" metaphor is hackneyed but nonetheless applicable: People only want to use a standard when adoption is sufficient to make the standard cost effective. While more than 100 public companies found it cost effective to participate in the SEC’s voluntary filing program, the ultimate information users – investors – required much greater adoption rates to make XBRL worthwhile. I don’t like where this metaphor is going, but effectively we had to force companies to lay eggs. Fortunately, they’ve been AAA extra large so far. Future implementations with lower adoption hurdles may not require mandates.

One reason to support XBRL adoption was to empower independent auditors to provide faster, better, and less expensive assurance by efficiently combining integrated software tools with professional judgment to create more reliable financial statements. If investors in private companies become accustomed to XBRL-quality data from public companies, perhaps they’ll demand similar information from private companies, where more highly-concentrated investors typically have more leverage over management. It certainly makes sense for private companies hoping to go public within a few years to start using XBRL well in advance to get ready for a fast and efficient IPO.

Moreover, with fixed costs for public companies for GAAP XBRL implementation, the cost to expand XBRL to other applications becomes mainly marginal. With the most complex data set – U.S. GAAP – out of the way, implementing the same or similar technology to automate other parts of the business information supply chain is more manageable. For example, XBRL GL looks much more attractive. Someday, a supermarket will scan the UPC bar code on a can of tomatoes and the dollar of revenue will end up in a 10-K without any human intervention except to monitor the systems that ensure straight-through processing.

If the U.S. is to remain competitive in the world economy, we have no choice but to improve efficiency by automating business processes. Much of that work not only can be voluntary – it must be voluntary because it’s the consequence of competition among businesses. XBRL is poised to win its share of competitions. A nice voluntary step, for example, might be XBRL support from Google’s Data Liberation team. With Google and other market participants throwing huge support behind open standards, XBRL will have to repeatedly prove its capabilities in the years to come.

3.  An argument has been made that financial regulators like the SEC primarily adopt XBRL to help their own analysts do their job more efficiently, and the needs of investors are a secondary consideration. To what extent do you think that argument has validity?

In my three-and-one-half years at the SEC, I never saw any air at all between the interests of investors and the interests of the Commissioners and staff. People at the SEC might sincerely disagree about the best ways to help investors, but everyone believed their primary mission was to help investors. The nice thing about XBRL is that it can help both government and private analysts do their jobs better.

It’s true that SEC analysts look for civil liability more often, while private analysts mostly look for investment opportunities, but there’s significant overlap. Either type of analyst is likely to consider whether a company has accurately disclosed all material information and either is likely to act on their conclusion. A private analyst decides to invest or not; an SEC analyst could call a company, issue a comment letter, or consult with the Division of Enforcement. While it could be a big mistake to trust a company just because the SEC hasn’t sued it, it’s also very clear that the faster and better the SEC can do its job, the less likely issuers can get away with fudging the facts. The roles of the SEC experts and private analysts are highly complementary to each other – not contentious.

Because so much money is at stake, and because resources for technology at the SEC are limited, I expect the private sector, not the SEC, to continue to lead the way in using XBRL. The SEC has considerable work to do to use XBRL to support more efficient compliance and surveillance. And because the legal environment in which the SEC itself works is itself enormously complex, the constraints won’t be technology. The SEC’s constraints will be legal and policy constraints.

What sort of data discrepancies are legally sufficient to justify imposing costs on public company investors to respond to an SEC investigation? How does one use technology to differentiate among skillful, lucky, and corrupt trading to show cause for a subpoena? Compared to questions like these, diversified investing (perhaps using XBRL to differentiate asset classes and industries and to identify different but potentially correlated investments) is easy.

4.  How do you think XBRL adoption by the SEC is proceeding? Do the issues described in the observations of SEC staff  on the statements filed thus far signal substantial problems? Or are they about what you had expected, or even relatively minor?

By all accounts, adoption is going well. The staff observations are informative. The first concern on the list relates to rendering, which is somewhat encouraging given that rendering isn’t particularly relevant to XBRL’s main purpose. After all, if you want the benefit of thousands of years of experience of putting ink on paper in a visually appealing way, you can still look at the dead tree format financial statements.

I also find it encouraging that the staff is urging filers to use standard elements. But that’s not a surprise either, since the use of standard elements helps investors make comparisons among companies and of performance over time. I expect the staff comments will be particularly helpful as the U.S. GAAP taxonomy is updated. As the taxonomy and the newly codified edition of U.S. GAAP become fully interoperable, tools using XBRL should make it easier for accountants and investors alike to visualize the importance of high quality accounting.

The really neat thing is that, before XBRL, the SEC found it difficult or impossible to hold third party data taggers accountable for the changes to GAAP in the normalization process. Now the SEC has tools to understand not only the official company reports but to understand how investors use those reports. The line of accountability, from companies to investors and the SEC, is much more direct. So is the feedback loop for GAAP itself. It will be interesting to watch how data about the use of GAAP is used to improve GAAP.

5.  At least in public, Mary Schapiro, the current Chairman of the SEC, has not been as outspoken as her predecessor, Chris Cox, on the importance of implementing XBRL for financial reporting. What consequences does this have for XBRL adoption at the agency? At this stage, with a final XBRL rule in place and adoption proceeding according to schedule, does commitment at the top of the agency make much of a difference?

To be fair, Chairman Schapiro has had quite a bit on her plate the past 10 months. And during his final year in office, Chairman Cox was extraordinarily busy dealing with the crisis of opacity via proprietary financial instruments, so he couldn’t spend as much time advocating transparency via open technology as he did early in his tenure. Fortunately, he identified XBRL as a priority very early. His experience with capital markets and technology dating to his service in President Reagan’s White House and earlier made XBRL a natural priority as soon as SEC technology director Corey Booth and the SEC’s first XBRL expert, Jeff Naumann, briefed him. Getting the process started early made it possible to finish with approval of the final public company rule in December 2008.

The most important time for the SEC to speak out for XBRL was during the work to develop the rules. With the roadmap now in place, there’s no reason for the Commission to be a backseat driver. What’s most important is for the Commission to support the staff’s work to make sure the SEC’s XBRL capabilities keep up with innovation in the private sector.

There’s always a place for leadership when it comes to transparency. Fair, fast, and efficient disclosure of asset-backed securities won’t happen without leadership from the top. I hope Chairman Schapiro and the rest of the Commission leverage the success of the GAAP and other XBRL programs to make ABS disclosure fairer, faster, and more efficient.
 

Trevor Pyman is Director and CEO of XBRL Australia Ltd. and an independent consultant to PriceWaterhouseCoopers (PwC). He has been heavily involved in the development of the XBRL taxonomy  for Australia’s Standard Business Reporting (SBR) program.

His comments are only his personal views, and do not represent those of the SBR program, PwC, or anyone connected with the SBR program.

1. What is Standard Business Reporting? What role does XBRL play in SBR? Is it possible to have SBR without XBRL, or are the two inextricably woven together?

SBR is a much broader concept of government agencies collaborating to improve business to government reporting. It could theoretically exist without XBRL, but the plain fact is that it could have occurred decades ago if that were the case. XBRL facilitates SBR by removing two significant roadblocks to inter-agency cooperation: (1) the need to agree on terminology between agencies and between business and government; and (2) the need to agree on the classification of things between these parties.

Obtaining agreement between government agencies on anything is a substantial task, so the less such agreements are needed, the greater the chance of success. The use of jargon is a natural human evolution in any economic activity, so it is counterproductive to try to eliminate it. Jargon is created to facilitate understanding, and XBRL taxonomies are likewise engineered to do the same thing. Allowing data concepts to be defined by many different references, each tailored to a specific audience, helps people understand how to use computers to share information. This runs counter to traditional IT thinking that dictates that every concept must be uniquely defined and everyone needs to agree on the definition.

XBRL says that you only need to agree that the concept is uniquely identified (so a computer can deal with it) and the people are free to use whatever human language suits them to describe it.

2. The SBR Conference 2009 included key figures from both the Australia and Netherlands SBR programs, as well as XBRL experts like Mike Willis. Do you foresee the formation of an international organization, perhaps along the lines of XBRL International, to facilitate adoption of Standard Business Reporting?

I would like to see that happen because it makes sense. SBR is a concept that is applicable to many governments and the infrastructure needed to implement it is common.

Little is gained by going it alone and repeatedly reinventing the wheel. Moreover, every new government that takes it on learns from those who went before and does it better, allowing the earlier implementations to evolve as well.

3. SBR implementations are currently being pursued in Netherlands, New Zealand, and Singapore. But the most ambitious adoption, beginning in July 2010, will be in Australia. Led by the Treasury, it will include the Australia Prudential Regulation Authority, the country’s Securities and Investments Commission, Australia’s taxation office, and the state and territory government revenue offices.
.
What factors do you see in Australia’s political and business environments that made it particularly hospitable for an SBR implementation on such a broad scale?

Reducing reporting burden is a common theme with governments around the world and has been for a while now. Economic downturns also bring the focus back to costs, and SBR is mostly about reducing cost in an area that adds little to business objectives. Not insignificantly, the Netherlands experience took much of the bravery out of the decision for Australia.

The key in both countries was political will. The endorsement and public support of a key political sponsor is essential. The technology is simple – the politics are highly complex.

4. As expansive as the planned adoption of SBR in Australia is, it is still primarily confined to fiscal and securities regulation functions. Longer term, do you see SBR being adopted by the Australian government and states in diverse areas like housing and law enforcement? What are the roadblocks to more widespread usage in government?

The biggest roadblock to government usage is probably government itself. There is a lot of talk about expanding the SBR approach into other areas, and this makes a lot of common sense – the problems it solves are common to most areas of information exchange. However, there is an enormous investment in the status quo. Many in powerful positions are huge beneficiaries of inefficiency and shifting the mindset is really hard, especially when very few have been exposed to the ways things CAN be done, rather than the ways things are done.

People who advise government have a vested interest in maximizing their time (and chargeable hours) in solving government’s problems, so efficiency and speed are often sacrificed to self interest. Proprietary solutions lock in future revenue streams for the provider that solutions like SBR would otherwise open up to competition through their use of open standards. As a new player, SBR-based solutions have a long way to go to break down long-established and well-financed barriers.

5. In a recent post on this blog, Nils-Bro Müller of XBRL Denmark wrote, even though XBRL’s benefits are well known, "Nobody seems to file in XBRL before it is mandatory to do so." However, SBR adoption in Australia, beginning in July 2010, will be on a voluntary basis. Are you concerned that Australia "will build SBR and no one will come"?

There is serious doubt as to whether SBR will achieve its target implementation rate without a mandate. The software vendors have long been asking for a mandate so they have certainty of a market for the functionality, but the SBR Program has resisted this.

One “problem” is that the reporting burden imposed by government is not that bad. While several hours of wasted time per quarter certainly adds up to a large amount of wasted time across the whole economy, it does not add up to a lot of wasted value. Small business people do not value their own time the way economists and consultants do, so they are unprepared to pay for software that gives them this time back.

Also, the government burden is only part of the reporting cycle in some cases and so automating only a part of the process does not create the efficiencies business is looking for. As soon as a manual step is introduced anywhere in the chain, the bulk of the benefits are lost.

I hope that enough vendors are encouraged to get into the market with XBRL-aware functionality that does more than just convert the existing output into XBRL format. Hopefully they will “see the light” and begin to use XBRL to make the entire process more efficient. Other uses (like online real time loan approvals) can then be offered that do resonate with the marketplace and thus kick off a virtuous cycle of adoption and benefits realization.