Neal Hannon, who writes regularly for Data Interactive, is an XBRL consultant and the former Director, Financial Reporting Technologies for the Financial Accounting Foundation (FAF). Active in the XBRL community since 2000, he served on the first XBRL US steering committee and has written over 60 articles on XBRL. You can contact him by email.
 
This first installment of a three-part interview contains questions one through four. Part  2 has questions four through eight; Part 3 has questions nine through twelve.

(1) The SEC has yet to publish its final rule for interactive data. But just on the basis of the December 17 meeting, did any of the announced revisions to the proposed rule surprise you? Are there any revisions you’d like to comment on?
 
First, I was not surprised by the six-month delay in the implementation of the rule.  The June 15, 2009, start will give both filers and XBRL software companies time to understand the details of the rule and have a smooth implementation. Second, I was surprised that the SEC chose to delay liability on XBRL filings for two years after a company’s first filing. Correct XBRL filing is not that challenging.  Most companies will get the tagging right the very first time. As always, additional surprises wait in the final rule. I will be particularly interested in what the final rule has to say about company-unique element extensions.
 
(2) On the liability issue, CFO.com reported that “Commissioner Luis Aguilar, a Democrat who joined the SEC earlier this year, criticized the XBRL proposal for sheltering companies when they first begin using the technology from some liability. He called the safeguards "unacceptable."” Do you think Commissioner Aguilar’s fears are legitimate?
 
The roadmap to full XBRL acceptance into the IDEA system is clear. In two years or slightly more, an XBRL filing directly into IDEA will be the most used method to file with the SEC. Companies will quickly adjust to putting every effort, including an audit review, into accurate and timely XBRL filings. The limited liability afforded by the rule will not significantly alter the safeguards surrounding SEC filings, mainly because the present system of EDGAR filings remains, for now, firmly in place.  The same can be said for financial information displayed on Yahoo Finance or MSN Money. Although the data aggregation decisions leading to condensed financial statements can be somewhat suspect, investors have mostly benefited from access to this information.  XBRL filings will be able to expose much more to the investors and should lead to interesting questions concerning the underlying accounting. This is a trade-off I’m willing to live with while we await “prime-time” as filed XBRL.
 
(3) Besides the SEC’s XBRL rule, what other developments in 2008 in the XBRL field do you believe were particularly noteworthy? Was there anything important you believe was not reported or underreported?
 
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. Secretary Paulson is in a much stronger position to make correct bailout allocation decisions because of the landmark work accomplished at the FDIC.  I understand that since the crisis began, the FDIC has expanded the number of questions asked of over 10,000 U.S. banks each quarter. Kudos to the FDIC!
 
Additionally, the worldwide growth of XBRL has been remarkable. The example the Netherlands is setting for the world is not only historic but visionary. Governments all over the world will soon be following their lead by asking how they too can reduce the regulatory burden on corporations by consolidating their requests for data to one coordinated request based in XBRL. The Australian government is attempting the same type of program right now. Anyone serious about reducing the size of our US government should take a hard look at these outstanding examples of win-win.
 
(4) In your presentations, you continually emphasize that, while XBRL can be very technical, it’s really all about the accounting.  Could you explain what you mean by that?
 
Back in late 2001, just after the Enron scandal, I was giving a lecture at the Northern Colorado University about adding XBRL to accounting courses. Mid-lecture, Lynn Turner, former SEC chief accountant under Chairman Arthur Levitt, stopped me cold.  He said that he was a big supporter of XBRL, but I had to promise him one thing. He asked me to never let the technology get ahead of the accounting. In other words, the accounting must be correct or the tagging is worthless. That theme has stuck with me.
 
The underlying accounting in XBRL consists of the standard label, the accounting definition in the label linkbase, and the authoritative literature in the reference linkbase.  I call these items the XBRL accounting triad. This is why the initial mapping from a company’s financial statements to the correct XBRL element is so crucial to getting the accounting right. If a label is chosen to represent management’s accounting intent, but the metadata associated with the element gives investors and the SEC a different signal, the accounting is not correct. In other words, a company can introduce an accounting error into their filings by making a bad choice of XBRL elements.
 
Software programs today will check for compliance to rules such as XML syntax, XBRL structure rules, and the like, but management is responsible for the accounting that goes into the tagging of their financial statements. With limited liability protection in place for two years after the first XBRL filing, this matter will not be super-critical. However, if the accounting in the XBRL filing is not right, it could be misleading. As much as the new XBRL US GAAP 2009 taxonomy has been checked, accounting problems will surface once 500 filers queue up to the EDGAR filing of interactive data.  XBRL US will need to stay on its toes and correct errors on a timely basis.

Written by Daniel Roberts     Posted on December 22, 2008

Daniel Roberts is the past Chairman of the XBRL US Steering Committee and a Director of RAAS Consulting Ltd.. Mr. Roberts can be reached by email.

On December 17, the SEC voted 4-1 to implement a final rule for the introduction of XBRL for reporting to the SEC. After a decade of hard work by hundreds, it is sad to see such a missed opportunity at this juncture.

There are four glaring problems with the new rule:

• Litigation relief
• No requirement to have the XBRL version of the financial statement audited
• Voluntary tagging of text in footnotes
• The roll-out schedule

How can this be? It seems sadly lacking, given that Chairman Cox, as recently as November 17, said:

For the SEC as well as for financial regulatory agencies around the world, corporate reporting is not an end in itself, but a means to achieving our missions. Those missions include protecting investors,encouraging capital formation, and promoting healthy markets. Every one of those missions will be better achieved with the widespread adoption and use of interactive data. Interactive data will also make disclosures more useful to investors, and to every market participant.

Only Commissioner Aguilar had the courage to vote against the rule, declaring that this was the first time in history he has seen the SEC weaken protections for investors:

I am not prepared to reduce the level of protection that I believe investors are entitled to. Using new technology to improve disclosure is a good thing — but not when it dilutes investor protection. In these times of market turmoil, investors need to know the SEC is looking out for them.

Let me quickly say that I have always been, and remain, deeply convinced that XBRL can and will revolutionize business reporting, both internal and external, and that XBRL has the ability to deliver incredible efficiencies across the business reporting supply chain. And let me add that, in the long run, the SEC's action last Wednesday represents a major step forward toward the full implementation of XBRL for financial reporting in the United States.

But for now, the specific inclusion of litigation relief, coupled with identifying the XBRL document as supplementary information and therefore not requiring an audit, makes a mockery of the dream of interactive data. What a boon for analysts and investors: an unaudited subset of a company's financial information, with no recourse should the company provide erroneous content. In order for the analysts and investors to actually place any confidence in the XBRL, they will still need to refer back to the original, audited, and filed financial information and footnotes.

Those familiar with the technical issues of XBRL -- and that is a very small number of people -- can list a number of situations that could "in good faith" result in errors in the XBRL that is produced. The SEC's rule will result in faster, cheaper, more detailed data -- and a virtually risk-free environment for the corporate executive who, in these particularly troubled times, decides to engage in financial statement fraud to attempt to influence investors to support the share price. The defense will always be that "a good faith attempt" was made to produce an error-free XBRL version of the financial statements.

Of course, the vast majority of CFOs and CEOs act in good faith to ensure that accurate information is provided to markets and regulators. Sometimes even acting in good faith errors will occur, and the audit process serves as an additional protection for the investor. So while the SEC might not require an audit for interactive data, it is my expectation that the majority of filers will seek assurance over their XBRL-tagged information. I can only say shame on any company that provides such information to the analyst and investor community unaudited.

Next, there is the issue of optional tagging of the textual content of disclosures. So often it is the text of the disclosure that discloses, not the numbers in subsidiary tables. Allowing filers to elect not to tag this text leaves analysts and investors right where they are today, having to sift through HTML or text documents to find the information buried in the text of the disclosures.

Finally, the schedule for implementation is slow enough to mean that all companies will not be providing XBRL-tagged information for analysts and investors until 2012. Peter Wallison, a member of the CIFR (Committee for Improvements to Financial Reporting), said in his dissent to the recommendations of the CIFR that:

...the Committee adopted an extended phase-in that will delay the widespread use of XBRL for financial reporting well into the next decade. I dissented from the Committee’s vote — and am filing this separate statement — because I believe the Committee’s proposed timetable is (i) based on an erroneous assessment of the potential costs of auditor assurance, (ii) applies restrictions on reporting that will be harmful to XBRL and to users, and (iii) unnecessarily delays the date on which XBRL will be available to investors and analysts.

I am confident that the SEC will review and revise the rule, and to be fair, the litigation relief does have a two-year window. But those two years represent a critical time period in which investor trust will need to be re-established for the markets to recover.

Unfortunately,Commissioner Aguilar's summary statement says it most eloquently:  "It departs from our best traditions,and shackles investors with the risks and costs arising from errors and misstatements in interactive data, even though issuers control the process of preparing the disclosure and are in the best position to ensure its accuracy and reliability."

So Chairman Cox gets the credit for “bringing the system of financial reporting into the 21^st century.” But someone else will have to make it happen.

Written by Hugh Wallis     Posted on December 10, 2008

Hugh Wallis has overall technical responsibility for standards development at XBRL International. He became involved with the XBRL Consortium in January 2000 while a software architect at Hyperion Solutions. Mr. Wallis was formerly Chair of the XBRL Specification Working Group, Chair of the XBRL-GL Working Group,and Chair of the XBRL Canada Domain/Taxonomy Working Group. He is a co-editor of the XBRL 2.1 Specification and other XBRL International technical products. Mr. Wallis can be reached by email.

The process of creating technical standards is one that is typically misunderstood by almost everyone -- even many of those deeply involved in it. The development of XBRL is no exception to this phenomenon. I hope this post sheds some light on how XBRL gets developed and helps dispel some of the misconceptions about this process.

There are a number of factors at play generating these misconceptions, and probably the most influential is one’s experience with software products. When a commercial company decides to produce and sell a piece of software, they need to bring it to market as fast as possible in order to start generating revenue; they then continue to develop and improve it based upon customer experience and feedback. This means that, following the alpha and beta stages (which are generally incomplete versions that are distributed to early adopters), a first version – Version 1.0 -- gets shipped that generally has some of the planned features not implemented. More important, there will usually be a number of known bugs – known to the developer, that is, but not necessarily publicly acknowledged. Then, with some money coming in the door that can be used to fund further development, coupled with actual implementation experience from customers, new versions are created and released on a regular basis.

So the marketplace is told that the 1.0 version is a “finished product” and is generally prepared to accept that at face value. Although the company usually continues to ship versions 1.1, 1.34, 2.0, 3.0 and so on, possibly for many years to come, the act of shipping the 1.0 version was a signal to the market that the product was “ready for prime time” (even if it wasn’t – which, regrettably, is sometimes the case).

Now, let’s contrast this with the process of developing a standard such as XBRL. A critical difference between a piece of software and a standard is that it should be very difficult, if not impossible, to change a standard once it has been RECOMMENDED by the body that promulgates it. The whole idea of a RECOMMENDED standard is to establish a stable environment that all stakeholders can rely on for a long time to come and which software developers can use to go and develop their products. Everyone involved can thus have a reasonable amount of confidence that those products will be able to talk to each other.

As an example, imagine a standard for light bulb fittings had been released (ignore the regional differences among continents with respect to screw thread, voltage, and so on). With this standard in mind, companies had gone out and created lamps, bulbs, and so on, and then it was decided that it should be changed to address some issue that arose during deployment. The huge investment made by many companies and consumers would be wasted and confusion would abound. So the key difference here is that the development of a standard actually comes to an end when it is RECOMMENDED, whereas the development of a piece of software could theoretically continue indefinitely.

It is precisely to avoid this kind of confusion and waste that the standards development process is what it is, even though that may appear slow and bureaucratic to the casual observer. There are, however, a number of parallels to the software development process described earlier that I’ll discuss.

The first time a standard under development is exposed to the public is in what is called a Public Working Draft (PWD). This may be an incomplete draft that might only satisfy some of the requirements and have some features which could be changed or removed altogether. There are generally a series of PWDs as the work proceeds.This is roughly equivalent to the alpha and beta stages in software development. As the PWD process draws to its conclusion, a last call is issued for any comments preparatory to promoting the work to Candidate Recommendation (CR) status.

A CR is the equivalent to a 1.0 version of a software product. It is complete (in respect to addressing all the requirements except those specifically listed as being “at risk”) and should be capable of being implemented by software vendors. This is really the point at which the marketplace should be thinking of adopting it, just as they would probably buy and deploy version 1.0 of new, cool software. Of course, a standards body such as XBRL International is nonprofit and does not generate its revenue from selling the standard; that aspect of the similarity -- and the motivation to “ship ASAP, preferably before quarter-end”-- does not hold.

At about this time, a call for implementations is made to get actual practical experience with the CR and weed out any issues that could affect stability of the final standard. This is roughly equivalent to getting user feedback on a 1.0 version of software. Additional CRs are generally published to address such feedback (akin to versions 1.2, 1.3, 2.0 etc. of software) and when at least two interoperable implementations are available and proved, it is time to move forward to the last step. This CR process could last quite a long time because it is only by actually implementing the standard, testing it in real life situations, and making necessary adjustments that one can be confident that it can be frozen as a RECOMMENDATION. Software is usually not considered to be “mature” until it has gone through a number of releases; the same applies to a standard, with the key difference being that once you have frozen a standard, it really is frozen.

Finally, the standard achieves RECOMMENDATION status; the only changes that should happen after that are minor errata corrections. If there is much that is more serious than that, then the consortium has not done its job properly.

I hope this has shed some light on how a standard such as XBRL gets created. If you want the detailed rules about the process, feel free to ask me, or, if you are feeling brave, you could even read the process document.