With XBRL starting to achieve momentum in the corporate world, the XBRL discussion turns the page to one that is focused on implementation issues.

Though the first two phases have already been put into effect, there is still a long way to go until full implementation of interactive data is complete. Only approximately 450 companies have filed detail tagged footnotes, approximately 1,200 companies began XBRL filing in 2010, and about 9,000 companies will begin filing this year after June 15.

For the few companies that have filed detail tagged footnotes, the process should get easier from period to period. However, the 2011 taxonomy is scheduled to be finalized in early 2011 and will be effective after July 15, 2011. But what is going to happen next? Will companies research better elements to replace existing or custom ones? On top of that, the modified treatment of liability will end on the two-year anniversary of XBRL filing. What are companies doing to get ready for the end of modified liability?

For those companies that have just begun filing or are about to start this year, are you downplaying the additional workload that XBRL filing will demand? Have you begun planning? Will you outsource or attempt to bring it in-house? If you are about to start detail tagging, do you have a plan in place to address all four levels of tagging? Do you have a proper review in place to ensure accuracy?

So far, this blog has been primarily aimed at business professionals who want to learn more about XBRL and who want to keep current with key XBRL issues as they emerge. We’ve stayed on top of the literature and told you what’s worth reading, as well as letting you know about meetings, webcasts, and other events worth listening to.

As we move into 2011, we will be expanding our focus to discuss how companies are implementing XBRL. Our goal is to help every company, no matter where they are in the process. For XBRL, 2011 will become “The Year of the Company.” We look forward to bringing you new insights from the company's point of view.

This is the third installment of a four-part interview. The first part provides an overview of XBRL CH; the second discusses the unique Swiss environment for XBRL adoption.

6. Switzerland, with its impressive tradition of political independence, is not a member of the Committee of European Securities Regulators (CESR), which has proposed a cost/benefit analysis of an XBRL mandate for Europe’s listed companies that contemplates a five-year phase-in period. How does Switzerland’s unique position vis-à-vis Europe and her institutions affect the implementation of XBRL FR for Swiss companies, both short- and long-term?

For political reasons, it is unlikely that Switzerland will join the EU in the foreseeable future. Nevertheless, the country is tightly integrated with the EU, to the extent that it has many of the benefits of membership but is not involved in political decision-making. The default model is called autonomous re-enactment. This is what I expect to happen for mandatory XBRL reporting as well. It is generally not in the DNA of Swiss authorities to take a leadership role by imposing onerous new regulation unilaterally, without extensive consultation and consensus building. So, short of a sudden burst of pioneer spirit, we will watch what happens in the EU, and then copy.

...More

This is the second installment of a four-part interview. The first part discusses the basics of XBRL CH.

3. The Big 4 firm Deloitte describes the financial reporting framework in Switzerland as follows:

Switzerland is not a member of the European Union and, therefore, is not subject to the EU IAS Regulation or Accounting Directives. The Swiss Foundation for Accounting and Reporting publishes accounting standards (ARR/FER, or 'Swiss GAAP'). Compliance with ARR/FER is required by all companies. However, compliance with IFRSs ensures compliance with ARR/FER, and many large Swiss companies have, for a number of years, followed IASs/IFRSs.

Starting with annual reports for 2005 and interim reports for 2006, most Swiss companies whose equity shares are listed on the main board of the Swiss Exchange are required to prepare their financial statements using either IFRSs or US GAAP. Swiss GAAP will not be permitted. The only exception is for Swiss companies listed on the main board that are not multinational (that is, operate primarily in Switzerland). Those companies may continue to use the Swiss GAAP, or they may choose IFRSs or US GAAP.

What impact does this FR framework have on both the development and use of a Switzerland-specific XBRL taxonomy?

It’s a major factor, which is often misunderstood. For us as the Swiss XBRL jurisdiction, it means that we don’t have the same evident Unique Selling Proposition in a single local GAAP taxonomy. In other words, all major firms already have access to a taxonomy covering their reporting needs, be it IFRS or US GAAP. There simply is no local GAAP requirement that Switzerland-based multinationals have to comply with.

Consequently, Swiss GAAP FER is a niche standard for small- to medium-size public and private entities, which is derived from IFRS, but without most of the complexity and associated cost. That is what makes it attractive; indeed, a few industrial firms have recently switched from IFRS to Swiss GAAP FER. However, the new IFRS for SMEs standard might lure some privately held preparers away from Swiss GAAP FER thanks to its immediate global recognition, which may be an issue for international investors and creditors. There is no Swiss GAAP FER taxonomy available to date, but we are certainly interested in helping to create one, once the initial OR taxonomy is done.

...More

XBRL is becoming more and more popular for financial, tax, statistical, and other reporting purposes. We have seen XBRL implemented in the US for the SEC, in the European Union for COREP/FINREP, and in Australia for SBR. But there are many other national XBRL projects … including those in Poland.

We started thinking about using XBRL in Poland in 2006. As a result, after a few meetings, the Polish jurisdiction of XBRL International (Association XBRL Polska) was established. Since then, awareness of XBRL in Poland has increased dramatically. More and more companies and, what’s more important, public institutions have recognized the power of XBRL in streamlining the reporting process. As a result, XBRL is now used in the banking sector (COREP and FINREP projects, see below), a Polish taxonomy for gathering annual reports is being developed, and other public institutions are cooperating with the association to use XBRL for other purposes (e.g., capital markets, tax reporting, etc.).

The first institution in Poland that decided to use XBRL was National Bank of Poland (NBP). NBP created both FINREP (FINancial REPorting) and COREP (COmmon REPorting) extension taxonomies. FINREP was designed for credit institutions that use IAS/IFRS for their published financial statements, while COREP was designed to create a harmonized reporting framework for the regulatory reporting of the capital ratio. Both taxonomies were based on COREP and FINREP taxonomies created by CEBS.

In Poland, COREP and FINREP assume submission of monthly, quarterly, and annual reports; using XBRL is obligatory. First reports were collected in the fourth quarter of 2007. Since then, about 650 entities have been involved; most of them are banks.

...More

In one of his recent blog posts, Dan Roberts referred to Europe as “the quiet revolutionaries.” It is certainly true that there is a feeling in financial information and business reporting circles that the “old order is being swept away” and that XBRL is stepping in to the fill the breach.

Unfortunately, what is sorely lacking in Europe is a harmonized pan-European equivalent to the SEC mandate for the disclosure of financial statement information in XBRL format or, as Dominic Jones so succinctly put it, “will Europe ever get its own EDGAR?” Vested interests, legacy investments, and the difficulties inherent in arriving at a binding Union-wide consensus mean that, while commendable progress can be made, the US experience has shown that a top-down regulatory mandate is indispensable in giving the jumpstart needed for the widespread adoption of XBRL.

Within Europe, while national initiatives are extremely important, their scope and effect tend to be limited by their jurisdiction. The recent blog post by Bob Schneider highlights the danger that institutional myopia holds for the development of XBRL, and more generally, for the future of financial disclosure in Europe. What is needed is a high-level, cohesive and visionary initiative with sufficient resources and political clout behind it to propel it through the bureaucracy.

...More

My “day job” is designing and building XBRL taxonomies. Despite my eight years of evangelizing through conferences and regular meetings with the major regulators and institutions in Portugal, XBRL remains little-known in my country. There was an expectation that the OTOC (Chamber of Chartered Accountants) would become the XBRL facilitator in Portugal, but now that seems to be on hold.

In some ways, it is surprising that XBRL has been slow to take off in Portugal. Regulators and institutions have heavily used XML in their filing programs. For example, a project called IES, developed by Bank of Portugal, Ministry of Justice, Ministry of Finance and Public Administration, and Statistics Portugal, is collecting financial, business, and accounting information through a form-based application or an XML file sent from companies' ERP systems. This is one of the most successful IT projects in Portugal.

Many of us think that bringing XBRL to IES would be a natural next step in XBRL adoption for Portugal. As it stands, financial institutions that are unfamiliar with overseas XBRL filing regimes remain worried that XBRL has to evolve more before it can add value for analysts and investors. Some hope that Portugal will follow the lead of the UK’s HMRC and mandate Inline XBRL (iXBRL). Inline XBRL hides machine-readable concept tags behind the legible captions, so that, for the first time, XBRL can be displayed in a browser exactly as the originator intended. This cuts out the middle-man between the reporting company and the investment analyst’s website. Inline XBRL allows the original financial report to be analyzed directly without the time, inefficiency, and errors related to cutting/pasting or transcribing company data into analysts' spreadsheets.

As it happens in many countries, the ultimate drive for adoption may come from America’s SEC. The SEC's requirement for XBRL financial statements is forcing the larger Portuguese companies to address XBRL; in 2011 those companies with SEC filing obligations will also need to file their financials in XBRL. This is already encouraging interest among the Big 4 in Portugal, and I am hoping that local software vendors will follow suit.

However slowly, whether from internal or external pressures, it appears that XBRL may become a reality for Portugal.

Written by Bob Schneider Posted on October 26, 2010

The final rule on interactive data requires companies to post the XBRL files they submit to the SEC on their corporate websites (see Section 2B5 Web Site Posting of Interactive Data, pp. 74-79). The rule states that the data be made available through the website address the company ordinarily uses to communicate with investors and that it remain posted for at least 12 months. The specific presentation, however -- appearance, design, location, etc. -- is not prescribed.

To examine how companies were handling presentation, I reviewed the websites of 100 companies selected at random from the XBRL Cloud EDGAR Dashboard. I wanted to know (a) whether the data was indeed available at the site, (b) the area of the Investor Relations section it resided, and, most important, (c) how it was presented.

It did not appear that noncompliance was a significant problem. Of the 100 companies, I could not locate XBRL data for five. As discussed in footnote 206 on p. 75 of the final rule, there are various provisions that extend the grace period for website posting, which may account for the absent XBRL files. I did not research each of these five exceptions, although I did note that three of the companies were recent first-time filers.

Of the remaining 95 filers, 61 – or about two-thirds – provided XBRL data in a format of which PetSmart provides a typical example. Drilling down from its Investor Relations gateway page to find the XBRL files for, say, a recent quarterly (10-Q) report, the user will:

...More

My grandmother used to say, for every pro there’s a con, and that’s certainly true of technological progress. Yes, technology speeds up data processing; yes, it automates routine tasks; and yes, it makes information far more accessible. At the same time, now we are overwhelmed by data; simple changes to system parameters require the involvement of specialists; and computer systems within an organization often are incompatible with one another — to say nothing of external systems.

Today, businesses fill out most reports – production schedules to suppliers, financial statements to shareholders, financial ratios to bankers, requests for government grants, and so on -- in formats that must be manipulated again and again along the information supply chain. Wouldn’t it be great if a company (or even an individual) could generate financial information and other data only once in a format that allows both internal and external users to integrate it instantly into their systems?

As readers are aware, such universality is precisely what XBRL offers. With XBRL, data no longer needs to be manipulated for each information request. Information is automatically exported into a readable and usable format by each user’s application; all users need to do is automatically import the data that is recognized by their systems without further manipulation.

Since this time- and money-saving solution already exists, the question becomes why it isn’t being used more often. The level of interest in XBRL in Canada among users of financial information is instructive.

...More

Written by Bob Schneider Posted on September 25, 2010

In response to the highly-criticized lack of transparency in asset-backed securities (ABS) – often cited as a key cause for the recent financial crisis and subsequent recession --- the SEC issued a proposed rule in April. Totaling some 677 pages, the Rule covers a multitude of complex issues concerning the offering process, disclosure, and reporting.

The purview of this post is far more narrow, limiting itself to the relevant text in the SEC proposal -- and, especially, the Comments to it -- regarding the use of XBRL. I believe the research and links provided will be useful to those who want to explore the possible use of XBRL for ABS reporting.

With respect to XML/XBRL, the Rule contains these proposals:

For each loan or asset in the asset pool, we are proposing to require disclosure of specified data relating to the terms of the asset, obligor characteristics, and underwriting of the asset. Such data would be provided in a machine-readable, standardized format so that it is most useful to investors and the markets. Under our proposal, issuers would be required to provide the asset-level data or grouped account data at the time of securitization, when new assets are added to the pool underlying the securities, and on an ongoing basis.

We are proposing to require the filing of a computer program (the “waterfall computer program,” as defined in the proposed rule) of the contractual cash flow provisions of the securities in the form of downloadable source code in Python, a commonly used computer programming language that is open source and interpretive. The computer program would be tagged in XML and required to be filed with the Commission as an exhibit. Under our proposal, the filed source code for the computer program, when downloaded and run (by loading it into an open “Python” session on the investor’s computer), would be required to allow the user to programmatically input information from the asset data file that we are proposing to require as described above. (pp. 16-17)

In its proposal, the SEC describes its reasons for choosing XML over XBRL:

We are proposing to require asset-level information and grouped account data (with respect to credit cards) related to an offering and ongoing periodic reporting be filed on EDGAR in XML as an asset data file….For asset-backed issuers, we believe that XML is the appropriate format to provide standardized asset data disclosure… XBRL allows issuers to capture the rich complexity of financial information presented in accordance with U.S. GAAP. In contrast, the proposed asset data file will present relatively simpler characteristics of the underlying loan, obligor, underwriting criteria and collateral among other items that are well suited for XML. We are proposing XML, rather than XBRL, because there are many commercial products that can be used with XML including parsers that would allow investors to insert data into a relational database for analysis, data extensions available in XBRL are not applicable to this data set, the nature of the repetitive data lends itself to an XML format and the schema could be easily updated. (pp. 190-2).

I performed a search on the Comments for keyword XBRL. Of the more than 140 Comments the SEC has received on the Rule, 15 mention XBRL. Six of the 15 -- Association for Competitive Technology, DTCC (Depository Trust and Clearing Corporation), JPMorgan Chase, TickLab partners, ABA Business Law Section, and Ariel Blumencwejg (structured credit trading professional) – make only in-passing and generally insignificant references.

Of the remaining Comments, those of XBRL US, UBmatrix, PwC, and MERS (Mortgage Electronic Registration Systems) generally support the use of XBRL. Mortgage Bankers Association, Mortgage Industry Standards Maintenance Organization, and Real Analytics are, to varying degrees, negative about the use of the data standard for ABS purposes. Risk Management Association and Microsoft are mixed or neutral in their assessments.

Comments Generally in Favor
XBRL US provides a detailed analysis that is well worth reading in its entirety. Here is an (oversimplified) summary of its main points:

1. XBRL US supports the use of the waterfall model, adding that “…Any such automated model must be consistent with the prospectus…It is important that the results of the Waterfall model match the prospectus as closely as possible.” (pp. 5-6)
2. It believes, however, that the output of the model is not clearly defined in the Rule. That output “should be in XBRL and, at a minimum, XML…XBRL is preferable over XML as the semantics associated with a cash flow are already incorporated into the XBRL standard….” (pp. 1-2)
3. The output should form part of a bond remittance file that represents the information about the cash flows associated with each bond. XBRL US has created a draft taxonomy to assess the feasibility of using XBRL for this purpose. (p.3)
4. XBRL is preferred to XML for capturing details of the loan file; in its Comment, XBRL US counters the argument that the sheer size of mortgage loan files makes XBRL impractical (bottom p.3).

UBmatrix has also provided a thoughtful and compelling response which deserves to be read in full. Summarizing its argument, UBmatrix states that:

The SEC proposal offers some key insights into how to help investors make sense of ABS filings. However, ultimately the proposed approach is undermined by a simple implementation detail -- the intent to use a Python-based computer program as the issuer's vehicle of delivery.

After outlining objections to a Python-based computer program (pp. 3-5), the Comment presents XBRL as “…a viable alternative, both as a mechanism for submitting ABS data and as a platform for modeling cash flows for investor analysis.” It enumerates five characteristics of XBRL -- data accuracy, data comparability, data transparency, extensibility, and sufficiency (i.e., the ability to offer a single solution that adequately meets issuer and investor needs, without the need to build or acquire from third party vendors) – that make it the better choice.

As part of a longer response to various ABS issues, PwC addresses the use of XML for the asset data files and states:

Adopting XML without also adopting an additional framework – be it XBRL, OAGIS, UBL or some similar public standard – means that numerous data file design decisions will have to be made by each reporting entity for the ABS disclosures. This may increase, not decrease, the variety of reporting formats and practices to the market…Some of the ABS disclosures, particularly those related to credit ratings (e.g. credit ratings, financial information on underlying properties, etc.), already exist in publicly available XBRL Taxonomies or dictionaries of common disclosure definitions. It would enhance the consistency of market use to enable the reuse of these definitions by all entities reporting and using ABS information.(p. 5)

Regarding cash flow waterfalls, the PwC Comment says:

We believe that providing a standardized basis for reporting waterfalls is useful, but that any programming language, no matter what the reputation is for readability, may be too technical to be easily understood by all potential users. Python is not a standardized information reporting tool. As such, it is possible to create Python code that returns correct results but is coded in such a way that may be very challenging for users to understand how the provided code creates the end results. The use of existing standards for the data (such as the use of the XBRL Specification to define appropriate taxonomies and instances for such data) and the formulas and business rules (such as XBRL Formula, RuleML, FPML or similar standard formula and rules languages) would facilitate the creation and population of waterfalls that are more easily understood and widely used by third parties while still allowing the standardized publication of online tools that work with these models. (p. 5)

MERS (Mortgage Electronic Registration Systems) includes this response to one of the SEC’s questions from the proposed rule:

SEC Question We note that there are several different standards under which asset-level data is already required. Would our requirements impose undue burdens on ABS issuers?
MERS Response MERS supports the creation of a common reporting requirement, and urges the SEC to work with other government agencies to harmonize the reporting requirements and move towards a common set of definition and data reporting requirements, optimally employing MISMO XML standards and XBRL. (p.6)

Comments Generally Against
The Comment of the Mortgage Bankers Association includes this section:

SEC Question In what format do issuers currently provide asset data information to investors (as may be required, for example, under transaction agreements)? Do any market participants currently provide asset data in accordance with a technical specification or schema commonly used across a particular asset class? If so, would our data points cause divergence from current practice? Please tell us which specific proposed data points would be of concern and why. How can we address those concerns? Is another format preferable, such as XBRL?
MBA Response ...XBRL is designed for the financial accounting industry and would require significant modification to be adapted to the U.S. mortgage industry. (p.54)

Mortgage Industry Standards Maintenance Organization, which is a not-for-profit subsidiary of the MBA, responds to the same question:

Issuers currently provide investors with information using multiple types of formats. There is no single format used for all disclosures across all ABS industries. Given that the type of data requested under the Proposal is very detailed, MISMO believes that XML is the better solution [emphasis added]. Within the real estate finance industry, MISMO XML standards represent the broadest implemented base of open, nonproprietary data standards in the real estate finance industry. (p. 19)

The Comment of Real Analytics offers this analysis:

Use of XML and Mortgage Data Standards
A central proposition of the SEC’s proposed regulations is to require that data pertaining to mortgage-backed securities and their related collateral be reported in XML. This proposition is consistent with the SEC’s similar existing requirement for financial reporting using a version of XML known as XBRL. Industry-specific versions XML are widely used in U.S. industries and throughout the world’s financial markets. While XBRL was developed for financial accounting purposes, it is not well suited for mortgage data or real estate. (p.1)

Other Comments
Risk Management Association includes this text in its Comment:

XML is a suitable format for asset data files and we support the use of XML schemas, specified either with the XSD language or the more specialized XBRL, to describe the required input structures.…We recommend that the SEC avoid using XML altogether in the representation, storage, or transmission of Python source code…Instead, we recommend that the SEC require that the waterfall computer program be submitted in the form of a text file, also known as a plain text or ASCII file. (p. 9)

Microsoft does note in its Comment that it is a founding company and ongoing supporter of XBRL. It is unenthusiastic about the waterfall proposal. It suggests a “data-oriented approach” similar to the Open Government Directive issued by the OMB on December 8, 2009; it does not mention XBRL in its recommendation.

In closing, let me reiterate that the XML versus XBRL question is only one part of the much larger debate of what disclosures and processes should be implemented for ABS. As this blog post indicates, the waterfall proposal itself has been subject to much scrutiny and is deeply controversial. How these larger reporting issues are resolved will inevitably determine what role either XML or XBRL will have in ABS reporting.

In December 2008, a law was signed in Germany to reduce the administrative burden of taxation (Steuerbürokratieabbaugesetz, or SteuBAG). Processes that used paper must now be replaced by electronic media.

In compliance with SteuBAG, Germany’s tax administration selected XBRL as the mandatory data standard for filing income statements and balance sheets. This requirement applies to all companies independent of size and industry. (However, companies that use cash-basis accounting – mostly small entities like restaurants, beauticians, etc. -- are not required to file in XBRL.) In some situations, XBRL filing will start in 2011, but the majority of companies will begin using XBRL in 2012 for filing 2011 financial statements to the tax authority.

To prepare for this transition, Germany’s tax administration has worked closely with the German XBRL jurisdiction to establish an appropriate taxonomy, including several industry-specific modules. The tax administration has invited all relevant German associations to join the working groups from the beginning to develop this taxonomy, a project called E-Bilanz.

During 2009 and 2010, the German local GAAP taxonomy was extended by positions and functionality to be in line with German tax law and regulations. One example of this work was identifying concepts that are mandatory for all companies. Subsequently, in February 2010, the tax authority announced that companies may choose to file either their local GAAP financial report plus reconciliation to tax values, or just the tax financial report.

Notably, the taxonomy contains both GAAP reporting positions and tax reporting positions as XBRL concepts. The legal context is that, in Germany, national GAAP has to be used for taxation purposes so long as no tax rule requires something different. This affords companies the opportunity to use XBRL with the same taxonomy for dual applications, i.e., filing to the business register and tax filing.

Using XBRL with the same taxonomy for both purposes aims to achieve a favorable cost/benefit relationship for the German economy, but there is the opportunity to improve this cost/benefit relationship further if XBRL is used for supervisory (i.e., regulatory) reporting too. As an example of one opportunity, consider that the reporting concepts for taxing insurance companies are based on supervisory reporting regulations. This could make it comparatively easy for insurance companies to file XBRL to their supervisory authorities in the future. It is a possible, next logical step, though it will depend on other developments, including those in the broader European context.

Within the next few weeks, German companies expect the tax authority to publish the draft taxonomy together with a proposed ruling about its usage.

(Editor's note: Readers may also enjoy Mr. Kesselmeyer's post The Use of XBRL for the German Business Register, published last week.)