XBRL News and Commentary from the Hitachi XBRL Business Unit
0

XBRL: Let’s Go to the Video Tape!

Written by Bob Schneider
Posted on July 31, 2008 Comments
July 31, 2008 | General | Bob Schneider

Written by Bob Schneider     Posted on July 31, 2008 

I’m sure I’m showing my age, but in the hundreds of times I’ve Googled for XBRL, I’ve rarely looked at the results in the Video section. Not surprisingly, when I finally spent some time there (and in the YouTube section too), I found some very good stuff. A Roger Ebert post on XBRL videos is definitely in order.  

So welcome to the 2008 eXBy Awards. The nominees for Best Interactive Data Video are…well, actually, I’ve included most of the watchable XBRL videos I found in Google results. (I haven't included so-called webinars, many of which would earn top ratings. I’ve also excluded any items from YouTube’s HitachiXBRL channel, which has the presentations of Mike Willis and Dr. James Canton at Hitachi’s NextFinance conference.)

How XBRL Works   A short video by Charlie Hoffman that does a superb job of explaining the essence of XBRL and its raison d’etre. Charlie takes a typical financial statement footnote and demonstrates how its text can be structured for meaning (as opposed to merely presentation). He makes the argument of why a global standard (i.e., XBRL) is necessary and valuable for tagging business information.   

How Can Companies Streamline Enterprise Business   Jeff Thompson from the Institute of Management Accountants (IMA) explains that the uses of XBRL extend beyond financial reporting to such areas as SOX compliance. Jeff emphasizes that XBRL is as important for internal reporting as external reporting. He expresses the support of the IMA for XBRL adoption.

XBRL in Plain English   This short, informative introductory video from Just Systems has lots of fun graphics and a cheerful narrative. I was put off, however by some of the overstatement, like “Information in a non-XBRL world is a terrible thing” or “No longer will companies be able to obfuscate financial information.” Still, the video is definitely worth recommending to someone who is completely new to the subject.

XBRL Convergence   A series of six videos (1, 2, 3, 4, 5, and 6), each eight or nine minutes, of Mike Willis’s presentation in June to the CalCPA Council. Mike begins with a discussion of convergence and explains how it’s a much larger issue than simply combining IFRS and US-GAAP.   He goes on to discuss XBRL in detail and how it will change the way financial professionals work.  A very good introduction. 

SEC Chair on XBRL   This video from 2006, with Chairman Cox discussing his plans for developing US GAAP taxonomies,  is now significantly dated. But it’s still useful for understanding how he views the benefits of XBRL for financial reporting.

The Business Value of Bringing XBRL into the SOA Fold -- Part 1  (NOTE: I had technical glitches trying to get this video to work.) Presented by Dianne Mueller and the staff of Just Systems, the video touches on a variety of topics, including the use of XBRL at the FDIC and SEC, the corporate reporting supply chain, and XBRL taxonomies. Dianne does a good job of putting XBRL into the broader context of all XML languages. Part 2 and Part 3 cover the technical aspects of XBRL solutions and are of more interest to developers and other IT specialists.

And the 2008 eXBy for Best Interactive Data Video goes to…
….Charlie Hoffman for How XBRL Works. Congratulations, Charlie!

In truth, it simply isn’t fair to compare videos of widely differing lengths and purposes and award one winner.  All of the nominees are to be congratulated, and I hope you’ll spend a little time checking out their work.

0

An Interview with Dominic Jones (Part II)

Written by Bob Schneider
Posted on July 23, 2008 Comments
July 23, 2008 | General | Bob Schneider

Dominic Jones, who writes the highly regarded IR Web Report blog and is a leading voice in the investor relations field, kindly agreed to do an interview with us. He is a principal of Clarity! Communications of Canada  and has more than 15 years of experience in journalism, investor education, and online investor relations communications. The second part of the interview, beginning with question (7), appears below; the first part was published last week.

(7) The SEC has tried to familiarize users with XBRL by making available several viewers with various types of data – company information, executive compensation, etc.. What is your opinion of these viewers? Do they do the job of convincing investors and other users that XBRL has something special to offer?

The viewers are quite basic in their functionality, but they are a good foundation for further development. It was important for the SEC to develop its viewers and make the source code available. But the best viewers will come when vendors start designing products based on investors’ needs.
 
One thing I don’t think the XBRL community realizes is that human-readable applications of XBRL, such as Microsoft’s Investor Central, are actually not as good or as usable as what is already being done on a few investor relations websites with considerable effort using old-fashioned, hand-coded HTML.

Some companies produce interactive quarterly reports in HTML that include functionality that is more sophisticated than that being done by Microsoft’s Investor Central. These HTML reports are being published simultaneously to the companies’ earnings releases, whereas Microsoft’s Investor Central is only updated several days after it has released its earnings. 

Of course, the companies that are currently doing things the hard way in HTML are going to benefit handsomely from the efficiencies that XBRL will bring. They will be able to do what they are currently doing in a fraction of the time and at much less cost.

It concerns me that the XBRL community has not managed to engage the mainstream web development community to use and experiment with XBRL data. My sense is that many people view XBRL as some kind of closed technology for financial software vendors and accounting firms. They don’t see it as open web technology similar to other semantic technologies.

(8) Advocates of interactive data say that the greater transparency and ease of analysis that XBRL statements offer will reduce the cost of capital for smaller companies. Others suggest that XBRL will have the opposite effect for at least some companies, revealing negatives that had previously been hidden. Do you think interactive data is a boon to smaller companies seeking capital, or do you think the advantages are overstated?

Both outcomes are probably true. Well-managed smaller companies will probably see benefits, while poorly managed ones will suffer. The same goes for big companies.

For me, the telling thing will be how management uses XBRL inside the business to make better decisions. Simply bolting XBRL on at the end of the financial reporting process might give investors data in a standardized electronic format, but it doesn’t help management beyond the opportunity to potentially be included in the universe of companies investors are applying their screens against.

If I am investor, a key data point will be to know if and how management is using interactive data inside the business. If XBRL allows investors to make better, faster decisions, it can do even more for you if you are managing and growing a business. In that sense, one of the most important tags in an XBRL filing with the SEC might be the one that identifies the vendor and technology a company used to prepare its XBRL documents – are they integrating XBRL into their internal reporting or bolting it on at the end by sending it to a financial printer?

(9) Companies now use their websites to varying degrees for IR purposes. The SEC’s proposed rule includes a provision that companies provide their XBRL files on their website simultaneous with their submission to the SEC. Overall, how do you see an XBRL mandate affecting the use of a company’s website for IR purposes?

By itself, the requirement to post XBRL files on corporate websites will have little or no impact on corporate investor relations websites. Companies simply have to post raw XBRL files on their sites. There’s no requirement to render those files in a human readable format or provide them via a web feed.

Until regulators recommend specific standards and recognize corporate website postings as being sufficient to meet broad disclosure requirements, companies will not invest in their websites. Interestingly, in countries where there were until recently no established newswire services or web-based regulatory databases -- such as Germany, Sweden, and even the UK -- companies have invested in their corporate websites, and those sites are on the whole much better than what you will find in the US.

Investors have been complaining for years that they want better web resources from US companies, but the vast majority of companies have failed to respond. I don’t think XBRL by itself will change that.

(10) Where do you see XBRL adoption three years from now? Do you think, as planned, most public companies will be submitting their financial statements and notes to the SEC in XBRL format? Or will there be numerous delays before a broad-based XBRL mandate is achieved? 

I don’t see anything delaying the proposed schedule because it is already very conservative. If anything, there is a strong case that can be made for moving a lot faster. And this might happen if new technologies come along that make it easier to tag financial and other information in XBRL and then distribute it to investors in real time at little or no cost. 

Even though XBRL has been 10 years in the making, we are still only in the very early stages of adoption. We shouldn’t forget that under the SEC’s proposed schedule, after three years fewer than half of US issuers will be tagging the face of their financial statements and their footnotes in detail. The rest will still only be tagging the face of their financials in detail and their footnotes will still be in block tags.

The MD&A will remain untouched. Proxy statements and the executive compensation information in them won’t be tagged. And perhaps most important, earnings releases won’t be in XBRL. Then there is still the problem of ensuring that XBRL data from one country is directly comparable to that from a company in another country.

So three years from now, I think we will still be waiting for the promised revolution that interactive data was supposed to bring.   

1

An Interview with Dominic Jones (Part I)

Written by Bob Schneider
Posted on July 16, 2008 Comments
July 16, 2008 | General | Bob Schneider

Dominic Jones, who writes the highly regarded IR Web Report blog and is a leading voice in the investor relations field, kindly agreed to do an interview with us. He is a principal of Clarity! Communications of Canada and has more than 15 years of experience in journalism, investor education, and online investor relations communications. The first part of the interview appears below; the second part will be published next week.
 
(1) What is your overall view of the SEC’s interactive data initiative? Was Chairman Cox right to make XBRL implementation an important priority of the agency? 

I do think it is an important strategic initiative when you look at it in a global context. Other countries have already moved to mandatory XBRL, including major economic powers like Japan and China. At the same time, the rest of the world is moving to a single accounting standard. And with investors easily able to invest anywhere in the world, there was a risk that US companies could be disadvantaged. I believe companies in countries where XBRL has not been championed by regulators to the same extent could find it harder to attract investors in the future.

Of course, Chairman Cox has basically had to ram XBRL down the throats of a reluctant audience, and he may need to do a lot more convincing. There have been few volunteers for the XBRL pilot program, which in itself should be instructive to the SEC about the lack of initiative that US companies take in communicating essential information to their shareholders. Our own research of how companies use the web in their investor communications has been consistent in finding that US companies are not leaders on the global stage.

The XBRL mandate will help US companies to catch up and take the lead over corporations in other countries. And I hope it will prompt companies to give more thought to how they are using technology to keep their investors informed and engaged on a broader scale.  

(2) Under the SEC’s proposed rule, about 500 of the largest US firms will be the first to submit XBRL exhibits, and other companies will be phased-in over time. Which comes closer to your point of view: (a) Good move. The big firms have the resources to do this with the least pain – let them go first. The smaller companies will learn from their experience. (b) Bad idea. This limited universe of only the biggest companies means whatever XBRL data there is will be mostly useless to analysts and investors. Implement it in one feel swoop for everyone.

I see the proposed implementation schedule as a political rather than a technical decision. It is a compromise designed to avert a backlash from issuers who already feel there is too much regulation that imposes unnecessary expense on companies, especially smaller ones. The SEC has shown it is very sensitive to smaller companies, as we have seen with the repeated delays in Section 404 of SOX.

From a public company’s perspective, there is nothing to prevent them from adopting XBRL earlier than required and making sure their data is included along with the first wave of companies. But I’m not sure how much there is to gain from being early because it’s not clear yet how and when data vendors and analysts are going to use XBRL.

Obviously, it would be better for investors to have access to data on the full universe of US companies much sooner. Even after the third year when all companies are filing parts of their 10-Qs and 10-Ks in XBRL, I think investors will still see it as only a small step towards what they really need, which is all corporate disclosures – especially earnings releases -- tagged in a machine-readable format, and faster reporting of that data.

(3) There’s been much discussion about whether assurance should be required for XBRL statements. Do you think analysts will ignore interactive data if it doesn’t have an auditor’s imprimatur? Or do you think analysts believe tagged data doesn’t require additional assurance and will happily use XBRL exhibits? 

Most of the people who are calling for third-party assurance over XBRL are connected to auditors and I think that makes people suspicious. I’m in the camp where I think it only becomes a big issue when something goes wrong and people start looking for ways to correct the problem. The fact is no amount of assurance from a third-party will be completely foolproof. People who want to commit fraud will find ways to do it with or without XBRL or an audit.

Some have argued that if you don’t have some kind of audit, then companies will play fast and loose with their data because there will be no one looking over their shoulders. I don’t fully buy that argument. I think they are overlooking the huge penalties that the market exacts on companies that issue unreliable information, and that is enough of a disincentive for firms to be sloppy in applying XBRL.

Finally, I see auditor assurance as a barrier to widespread adoption because it will impose additional, unknown costs. But if a company decides it wants to have its auditors give their stamp of approval on its XBRL data, then they should be free to do so. This will likely give investors greater confidence in the data, the benefits of which could more than offset the cost of the audit.

(4) Thus far, most IR professionals have not shown great interest in XBRL. What do you think are the main reasons for their indifference?

Most US investor relations officers (IROs) are not directly involved in disclosure technology and have a very poor understanding of it. This is mostly because about 75% of investor relations sections on US corporate websites are outsourced to hosting services. IROs have generally been entirely hands off when it comes to these sites so they’ve lost out on a lot of important learning over the years. They don’t understand what HTML is, so XBRL is even more alien to them.

And because their clients are oblivious, the two major firms that host investor relations websites have had little reason to innovate or implement best practice. I don’t expect this will change much because IROs mostly will not be directly responsible for implementing XBRL inside their companies, although they may be part of the decision-making around which tags the company is going to use.

Of course, once XBRL data is in the hands of investors and analysts, IROs will be on the frontlines dealing with the questions. But until that day comes, IROs don’t have an incentive to pay attention to XBRL. Unfortunately, a lot of IR departments are probably in for a rude awakening when analysts start asking more detailed questions once they have XBRL data to work from.
 
(5) Overall, how do you see the role of IR professionals changing because of interactive data? What difference will it make in their day-to-day activities? Do you think XBRL adoption will create greater opportunities for IR practitioners, or will it reduce the need for their services?

In the short-term, there will probably be a lot more need for IR practitioners who can explain their companies’ accounting decisions to analysts and investors. I expect that there will be a lot more questions of a technical accounting nature.

In the longer-term, however, my view is that XBRL will commoditize historical financial data. There’ll be less reason for analysts and investors to devote time and resources to formatting and analyzing data from the past because there will be little to gain from doing so if everyone has the same information and the same ability to analyze it using computers and software.

At this point, the focus will probably turn to external factors and to more analysis of a firm’s future potential. IROs will be under greater pressure to explain their companies’ strategies and the context in which their businesses operate. The ability to communicate these soft factors to investors will become much more important. They will need to become more proactive communicators.

I guess I am saying that by making data easier to analyze, XBRL will make data somewhat less valuable while factors that are not easily measured, such as management credibility or innovation, will become much more valuable.  

(6) How does XBRL adoption change the education and experience requirements for IR professionals? How would you suggest both new recruits and experienced IR pros prepare for an interactive data mandate?

I don’t think it changes the requirements much by itself. But as part of a broader trend of increasing use of technology in disclosure and communications in general, I expect that IROs will need to become much better communicators and much better at understanding how to use technology to ensure that their companies’ stories are reaching investors.

XBRL is going to give analysts and investors more time to research what others are saying about companies. And much of what is being said about these companies will be online. IROs are going to have to understand more about how to use new media and how to monitor and respond to what is being said.

However, the basic requirements of a good IRO will remain the same: a good understanding of how investors make decisions; a solid understanding of accounting; and outstanding communication skills.

0

Companies Slouch Toward XBRL Mandate

Written by Bob Schneider
Posted on July 15, 2008 Comments
July 15, 2008 | General | Bob Schneider

Written by Matt Kelly     Posted on July 15, 2008

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

Not long ago, Compliance Week polled its readers — financial reporting and corporate compliance executives — to see how prepared they are for the XBRL mandate hurtling towards them from the U.S. Securities and Exchange Commission (SEC). The results were less than encouraging.

It’s true our survey did go out in early June, just after the SEC published its proposed rule to mandate XBRL technology. Perhaps the results are a snapshot in time, and will improve in coming months as the XBRL mandate comes closer to (and eventually becomes) reality. But from what we saw, the picture right now is a raucous high school class: everyone still doing his or her own thing, while the teacher pleads for them to pay attention.

Specific findings include:

• Of the 236 respondents, 104 (or 44 percent) said they had just begun researching XBRL and their companies had done no previous testing. Another 26 respondents (11 percent) said they had no knowledge of XBRL at all.
• A substantial majority of 79 percent said their companies had no XBRL expert on staff at all. Nineteen percent had an expert on the financial reporting team, and 2 percent had an expert in the IT department.
• Sixteen respondents (7 percent) participate in the SEC’s voluntary filing program. Another 6 percent say they’ve done some small pilot tests, and 2 percent say they’ve been testing their own systems comprehensively.
• Some 30 percent of respondents say their companies haven’t yet tested XBRL, but say they’ve been following the topic closely.

What’s more, the results suggest that large companies — the ones that will start adopting XBRL probably in a matter of months — are just as unprepared for the change as small companies. Of the 47 respondents with 20,000 or more employees, 34 percent had either just started researching XBRL or done no homework at all. Thirty-eight percent of companies with $5 billion or more in annual revenue were in the same predicament.

The SEC is not sounding any alarm bells yet. Officials there believe most of Corporate America will come around to the reality of XBRL soon, and they’re probably right. Standard procedure among most corporations is to ignore any new rule from the SEC until the last minute, and then scramble to comply with it as quickly as possible. That’s what happened with the Sarbanes-Oxley Act four years ago, and that’s what is happening now.

The SEC also has one invaluable card to play: XBRL genuinely isn’t as hard to implement as SOX and its dreaded Section 404 provision. That had been everyone’s fear two years ago, when SEC Chairman Christopher Cox began his campaign to make XBRL the law of the financial reporting landscape. But Compliance Week has been keeping tabs on the several dozen companies participating in the SEC’s pilot XBRL program. Almost universally, their opinions boil down to: “Oh, that? It was confusing for a quarter, but then it wasn’t anything special after that.”

Words to warm any securities regulator’s heart. And words to suggest that, despite the current confusion, the SEC may yet just pull this XBRL thing off.

0

What Features Should You Look For in XBRL Software?

Written by Bob Schneider
Posted on July 14, 2008 Comments
July 14, 2008 | General | Bob Schneider

Written by Peter Boritz     Posted on July 14, 2008

Peter Boritz is the chief technology architect for Snappy Reports XBRL. In the first part of this article published last week, he offered an overview of XBRL software and general advice on what to buy. In this second and final installment, he provides a list of features to keep in mind when purchasing XBRL products.

1. A good software program should be visual and intuitive and easy to use. Although the tasks at hand may seem complex, a good software program dissects tasks down to an understandable array of accomplishments that can be completed through a step-by-step approach.

2. The software should be able to extend private and published taxonomies. A published taxonomy is most likely produced by a regulatory agency, as the US-GAAP is. Your business may create private, internal extensions to published taxonomies for specific uses. An example might be for a filing company that has many clients in the trucking business. It could create a taxonomy extension to the US-GAAP specifically for their trucking business clients. Each client could then extend the trucking business extension to the US-GAAP, as required.

3. Software should be able to create reporting period contexts and allow users to specify some basics, such as currency type (if applicable) and numeric precision. A reporting context defines (1) whose data is it (who) (2) the reporting period (when) and (3) a unit of measure, such as dollars or euros (what). The who, what, and when defines an XBRL object referred to as a context.

4. Software should be able to create reporting segments. A reporting segment provides additional information regarding a context.

5. Software should be able to extend taxonomies for new elements, labels, and references from within the program. This is very handy when the element you want does not exist and you would like to create it on the fly. A good mapping program should allow you to extend and map from the same dashboard. A good filing program should allow you to do the same. In both cases, extending an element not only refers to creation of an element, but also creating a corresponding label, and all necessary arcs and locators required to do the job.

6. Locators are more technical than users need to understand. A good program handles locators implicitly, without the need for users to know or understand what they are, or that they exist.

7. Arcs should be created indirectly through intuitive operations. Users shouldn’t have to know what an arc is or does. Users should be able to drag and drop objects into place and handle specific operations in relation to objects selected. Arcs should be created and maintained through functions users perform, not through a technical understanding of what an arc is and does.

8. Users should be visually able to see report totals, and be able to distinguish calculation arcs from dimension domain member totals. A good filing program will calculate and display totals as changes are made to the filing. Totals may take two flavors: (1) dimensional domain member totals, or (2) totals determined through calculation arcs. Real- time totals are necessary in order to quality-control your filings against your data source, such as an Excel spreadsheet or other document.

9. It should be able to create dimensional and calculation total (arcs) for newly extended elements. In many cases, when you extend for a new element, the newly created element has siblings. Those siblings have mathematical relationships that must be mirrored in the new element. For instance, if you create an extended element for construction payables, and that element is a sibling to accounts payable, construction payables must be included in all calculation arc totals that accounts payable participate in. The same is true for dimensional domain member relationships, defined in the definition link base.

10. It should be easy to drag and drop, type, or map business data into filings. Many Excel-based programs have users dragging taxonomy elements into Excel data cells. Stand-alone programs generally do the opposite. They drag data from spreadsheets or other data sources to elements in the filing. Both equally achieve the same purpose. Neither is preferable to the other.

A spreadsheet displays data the way users work. The process of dragging and dropping requires that elements be displayed side by side. The preferable format for displaying elements is in a format similar to the spreadsheet. This is not as difficult task as one may think. Software can display elements in one of many report formats. For instance, if you are working with a balance sheet or income statement in your spreadsheet, a good software program should be able to render the taxonomy as a corresponding balance sheet or income statement along side. This makes it easier to relate your data source to the taxonomy and provides excellent groundwork for maintaining quality control.

11. It should provide filtering mechanisms in order to narrow down the scope of possibilities. The US-GAAP contains over 12,000 elements. Possible flavors of filtering include:

a. Industry level filtering. The US-GAAP (March 2008) provides for filtering based on one of five industries:
• banking
• brokers and dealers
• commerce and industry
• insurance
• real estate
Most businesses would most likely fall under commerce and industry. Choosing the industry first filters out elements not specific to your industry of interest.

b. Role module (report) filtering. This allows users to visually display a reporting module within the taxonomy in presentation view (as it would be printed). For instance, if you have a balance sheet-related concept, role module filtering shows you the balance sheet and only those elements within the balance sheet.

c. Sounds-like filtering matches concepts to elements based on word pattern matches. For instance, if the concept contains the word revenue, a pattern matching filter might display all elements that also contain the word revenue.

12. Mapping and its corresponding data should be persistent. That means you load data and map once and you are done. A good program will allow you to load data once and re-use it against multiple taxonomies.

13. Mapping should provide an inventory of unmapped facts. Unmapped facts will never show up on a report, but they must be accounted for. Some facts are intentionally not mapped -- for instance, if you are bringing data from your financial system or spreadsheet for total assets. If total assets is calculated within the taxonomy, mapping in a total assets value may multiply the result in some programs, others will do a comparison and generate an error if the two do not match.  You must still be able to account for the fact that total assets is intentionally not mapped. There may be other data facts that are mistakenly not mapped. An audit list of mapped and unmapped data facts must be clearly displayed.

14. A good program makes the mapping process easier. You should be able to map based in relation to a report module. This means focus on mapping to the balance sheet or income statement, one at a time. You should be able to filter down to parts of the report as necessary. For instance, work with only the liabilities or payables section of the balance sheet. A good mapping program provides mechanisms to extend taxonomies by being able to create extended elements from within the mapping tool and then be able to map to those extended elements from a single dashboard.

15. Filing programs should be able to track the people who entered and made changes to the filing and the date and time of changes.

16. Reports need to be produced in human readable format. Popular possibilities include web, Excel, or Word. Other possibilities may include postscript.

17. Elements should be displayed in label view and be translatable to other languages. Language translations are built into the taxonomy. The US-GAAP is currently English only. The IFRS has translations for most languages spoken throughout Europe, including Spanish, French, and German and a host of others. You cannot expect people in foreign subsidiaries to work properly unless they can visually see elements in their native language.

18. Software should be able to map to elements relative to tuple attributes. Although tuples are not used within many taxonomies, they are still part of the specification and need to be addressed.

19. Software should ensure that abstract elements are not mapped to. Abstract elements are for organizational purposes only. They cannot be mapped to.

20. Software should ensure that published taxonomies, such as the US-GAAP, are not internally modified in any way by the program.

21. For internal reporting, be able to extend dimensional domain-members for proprietary business facts.

22. For the security conscious, only those users having logins and passwords should be able to have access to the software. Some programs allow administrators to grant and deny permissions to people for specific tasks, but not others. For instance, taxonomy developers may not have access to data or vice versa.

23. Finally, software should provide easy access to external references. Many programs display references through a pop-up tool tip that is displayed automatically as the cursor travels over a related element.
 

0

An Interview with Walter Hamscher (Part V)

Written by Bob Schneider
Posted on July 11, 2008 Comments
July 11, 2008 | General | Bob Schneider

As many readers know, Walter Hamscher is an XBRL pioneer and one of the smartest people in the field. He recently gave us a wide-ranging interview in which he discussed a host of XBRL topics, including the SEC's proposed mandate, the pace of XBRL adoption in the US and abroad, assurance issues, and Inline XBRL. The fifth and final installment of the interview, which begins with question (12), appears below. The first, second, third, and fourth parts were published over the past few weeks. 

(12) One of your special strengths is communicating technical topics to diverse audiences in plain English. It seems that XBRL poses a special challenge in this regard, i.e., it's very hard to explain even the rudiments of XBRL without getting highly technical very quickly. Do you think it's possible to give general business audiences a sense of what XBRL is in plain English?

Well, I used to think that and I think it's still possible. But I would certainly say that as a community we often expose way too much of the technology. The reason we've had to do that is because we haven't paid enough attention to the applications, so we wind up talking about the data format, and the taxonomies, and showing people angle brackets.

For example, you can use the Web for years and only know that there is thing called a browser; you don't even know that there is a thing called HTML. Whereas we have done it the other way around. We talk a lot about the language without really focusing on applications; there is no fully defined notion of an XBRL browser, there is no basic application that uses XBRL. There is also this kind of mental wall between using Excel spreadsheets and using XBRL. We never should have let that wall grow up between the two ideas.

People are going to use spreadsheets. Spreadsheets are incredibly powerful, they are a great idea; we really should be talking about how XBRL is something that makes the data in spreadsheets more consistent, more usable. It's very easy to find text on the web that makes it sound as if XBRL is some alternative to spreadsheets. I mean that is just silly, it's not an alternative. It's an improvement to spreadsheets.

I would go so far as to say that even if I never see another application other than Excel using XBRL I would be happy. That is not a problem for me, but for whatever reason there are not enough Excel-based applications, plug-ins, and alternatives to make XBRL come alive for people.

So we talk about the standard, we talk about the taxonomies. The reality is that, instead of talking about the taxonomy, we should talk about -- it should almost be like a hidden sheet within an Excel Workbook. “Oh, and by the way, this hidden sheet has a bunch of definitions in it,” and so on. We would be a little further along in having people be familiar with XBRL, but we always talk about the data structures rather than the application.

Well it seems to me you're almost saying that the underbelly of XBRL, all those angle brackets -- it’s not worthwhile trying to explain that to people. We should just go ahead and try to develop applications in the same way we use a browser, where most people don't worry about the HTML at all.

I wouldn't go so far as to say that we should ignore it, but let me put it this way. I had to write the Preparers Guide for the US GAAP Taxonomies, and it was frustrating because I couldn't refer to any particular application or set of specific operations that one would do.

I can make all those operations and give them names, and give them a sequence, and never actually refer to the software and then talk about things like axis and dimensions and so on. I don't really think that most users need to know that anymore than when they are creating a chart in PowerPoint they really need to know how all that stuff works underneath.

How exactly that line is drawn I don’t know. But I think that is, unfortunately, where we are. If I had it all to do it over again, I know that I would have liked to spend a lot more time on simple applications and Open Source software to get the stuff into the hands of developers so that they could actually be used in existing applications.

I think we have a complex specification because financial reporting is complicated, and it's going to take a while for all the software to catch up to it. But once the software does catch up, I think people will see enormous value in XBRL and they will do things with it we haven't even thought of.

(13) Where do you see the future of XBRL? Do you think it will go beyond the financial realm to become the lingua franca for all business information? Is there anything specific the XBRL community should be doing now to foster its use? I think you have answered that to some degree in discussing the development of software, but is there anything you would like to add?

For our current XBRL community, it’s very important that they go get the free products, download them, try them, and give feedback to the vendors. Even if the feedback is “I couldn't get it to work,” that’s valuable to the vendors.

It’s the vendors who are in this community that have invested a great deal in it. In contrast with that investment, I don't sense that they get enough useful feedback from the XBRL user community. I don't think the vendors are quite getting the feedback they need about what are the simple features that their tools need in order to make all this usable. I think if everybody who went to the Eindhoven Conference would spend a few hours downloading the free tools and try to use them, and then just send a note to the vendors and say, “this didn't work, but that did,” that would be a great, great, great thing. Because I just don't think that happens enough.

The other part of your question was whether I think XBRL is going to be the lingua franca for all business information.  Actually I do, and I think that the evidence for that is that there is absolutely nothing else on the horizon that comes even close.

So the first question is, will there ever be a lingua franca? You can believe that or not believe it.  But if you do believe there is going to be one, then XBRL is definitely going to be it -- there is no alternative.

So then the question becomes, is the lingua franca needed? Well, I think with the globalization of markets and the globalization of all kinds of reporting -- including business performance metrics and sustainability reporting – it’s obviously yes; there's a huge number of other opportunities for XBRL.

We just need the software, and we need the community to really get engaged in trying the software and giving feedback to vendors.

1

XBRL Software: A Buyer’s Guide

Written by Bob Schneider
Posted on July 7, 2008 Comments
July 7, 2008 | General | Bob Schneider

Written by Peter Boritz     Posted on July 7, 2008

Peter Boritz is the chief technology architect for Snappy Reports XBRL. In this first post of a two-part article, he offers an overview of XBRL software and advice on what to buy. The second part describing features to look for in XBRL products will be published next week.

Looking for XBRL software can be a perplexing task. Understanding XBRL and the many requirements necessary for you to run your business can be challenging, and software features can vary greatly among vendors. So how do you determine which is the right XBRL software for your business?  Some initial questions to ask include:

• What are the goals and objectives of your XBRL implementation?
• Where is your XBRL data coming from? How will you be delivering and processing it?
• What security issues do you have? How will you dissect and distribute tasks and privileges to authorized users?

Minimally, any program needs to be able to create instance documents and extensions in XBRL format. This is the end result of our labors.

Uses for XBRL generally fall into one of two categories: external reporting for regulatory compliance, or internal reporting for data consolidation and reporting.

External Reporting
External reporting applies to regulatory compliance with government agencies. An agency publishes a taxonomy that functions as the basis of the reporting. For the Securities and Exchange Commission in the United States, that taxonomy is either the US-GAAP or the ICI Risk Return.

Specific reports are built into taxonomies. These may include the basics, such as balance sheet and income statement, and may span out to a wide range of other items, depending on the nature of the information desired to be collected. Reports may collect a combination of numerical financial information, as well as text-based disclosures.

A good XBRL implementation allows users to work with taxonomies on a report-by-report basis. This means you might see the balance sheet in human readable format, and work with just the balance sheet or income statement as circumstance requires. The US-GAAP incorporates over 12,000 elements. To work without having at least a report display and filtering mechanism makes the process confusing and tedious. Being able to filter through taxonomies is imperative for any software product you choose. Better programs allow you to filter through specific sections of reports, such as just the payables portion of the balance sheet.

If you are entering numerical data into a filing, a good implementation displays totals in real time as data is entered. These totals can then be compared to the spreadsheet or other data source being used as the basis of the filing. When you see totals in the filing equal to that of your source document, you at least reasonably know that all values have been accounted for.

Internal Reporting
XBRL provides a very powerful process for data consolidation and reporting. Company policies and procedures can be expressed through one or more taxonomies that define business data and the relationships of the data from which the organization operates.

The problem of businesses operating through personal spreadsheets used privately by employees becomes a thing of the past. All business data can be consolidated and distributed to those authorized from a common repository design, based on business concepts expressed through one or more taxonomies.

Architectural Configurations of XBRL Software
XBRL software generally falls into one of two architectural categories.

1. Excel spreadsheet add-ons are accessible from within Excel. Many professionals using Excel in their jobs feel comfortable using software that supplements Excel features. The advantages of an XBRL ad-on are familiarity and ease of use.

Since this architecture is dependent on Excel to operate, Excel add-on programs are limited by the scope of Excel’s capabilities. Excel interface programs are single user programs, as Excel is. Data sharing is limited to distributing spreadsheets from desk to desk. They work well for single proprietor businesses or in cases where filings are handled by one person and one person only.

2. Standalone XBRL programs are designed specifically for XBRL. They are limited only by the functionality offered.

Key differences are how or if data is shared among users.

a. Single user standalone programs Single user programs are designed for single practitioners and companies having a one-person external reporting manager.
b. Enterprise programs  Enterprise programs allow for the exchange of ideas throughout the business. This includes business data, taxonomies, and extensions. Enterprise programs may take the form or either multi-user single database applications, or distributed databases accessed through an internet or network protocol.
c. Networked programs Networked programs are designed for a wider scope of development where users need to be able to access multiple independent databases and projects. This is distinguished from enterprise in that each project/database is independent of each other and each has its own access security, personality, and protocols.

Data Integration
Integration is the process of bringing data from your spreadsheets and financial systems into XBRL. At a minimum, software should be able to process spreadsheets, since spreadsheets are an integral part of any accounting professional’s toolkit. A good software product should also be able to import data from most business systems. Methods for importation of data can vary from product to product. Some products allow data to be imported once, and then re-used for multiple applications of the data. Others require a data import for each application, even if the data being imported is the same.

Seamless and Disparate Solutions
Software architecture can vary greatly. Some software products implement a seamless solution using a common data repository. This allows users to set up connections to enter content and others to retrieve and process data. Other systems are unable to do this. They may rely on third-party products to transform and transmit instance documents, and then re-transform them at the other end. For most applications, a seamless solution is preferable. Software that does not implement a common data repository or is lacking in taxonomy/data connectivity between servers must generally transform and re-transform instance documents as a substitute.

0

An Interview with Walter Hamscher (Part IV)

Written by Bob Schneider
Posted on July 4, 2008 Comments
July 4, 2008 | General | Bob Schneider

As many readers know, Walter Hamscher is an XBRL pioneer and one of the smartest people in the field. He recently gave us a wide-ranging interview in which he discussed a host of XBRL topics, including the SEC’s proposed mandate, the pace of XBRL adoption in the US and abroad, assurance issues, and Inline XBRL. The fourth part of the interview, which begins with question (9), appears below. The first, second, and third parts were published over the past few weeks; the final installment will appear next week.  

(9) At the recent XBRL International Conference in Eindhoven, you gave a presentation on how Inline XBRL can simplify some of the problems that arise for regulators seeking to encourage preparers to submit full financial statements and other formatted documents. Could you give us some idea of what Inline XBRL is, along with some examples of what it can accomplish?

Most people have been using Internet browsers now for years. They are familiar with the notion that you can be looking at a page, rolling your mouse over parts of it, and it may pop-up things or may change colors -- things can happen in my browser as a consequence of that.

People are also very familiar with the notion that when you send an email and, say, you attach a file to it, they don't know anything about how it actually might work inside, but they know conceptually the notion of attachment and those related functions.

Inline XBRL is really a way of saying: “Here’s an HTML page on a website and it contains financial information you can extract and use immediately.” Inline XBRL is a way of putting the XBRL right into that web page, so that if you have a browser or other application that understands that it is there, you are going to get a new, additional, and better behavior. You will be able to extract the data from it at the consumption end.

From the production end it solves an important process issue that we've had really for quite a while. If I am a preparer today, and I’m in the voluntary filing program, I have to produce my 10-Q or my 10-K, and then I have to do this bolt-on process where I have to take that document, make a new XBRL document, and then manually check each one of the hundreds of individual facts back against the original.

This is terrible; it would make a lot more sense to do it the way you would do it in Word or something like that. That is, initially put the data right on to the original file itself, put it into Word the way you already put bookmarks in the file, or put styles on characters; things you already know how to do well. That way, there's no checking to do; it can't be wrong, because you've actually put the tagging of a fact or number into the file right at the same place.

So in my mind, it solves two adoption hurdles for XBRL in the US. My only regret for Inline XBRL is that we didn't get it done six months earlier.

(10) Could you talk a little bit about the development of Inline XBRL?

Sure. It goes back to a very early conversation we had in 1999 when we were first designing XBRL. We were making the observation that it would be nice if you could take any news story -- because in 1999 it was kind of a new and novel idea that news stories were being posted on the web -- and actually stick XBRL right into the web page. That was an initial thought about how XBRL could work. Then we went off for six years and did other things.

Now in the course of building more XBRL taxonomies for other agencies around the world -- and in particular for the mutual fund industry’s Investment Company Institute -- it became clear to me that there was a comfort level that people will need with the XBRL document. They needed to be able to see it on their computer screen, and the appearance needed to be familiar -- it needed to be what they intended to put in there. And they were okay with the idea that “OK, I am going to put some tags in here.” But the idea that the tags were all scrambled up in a random order and that they then have to be re-assembled causes a lot of understandable discomfort in the minds of people who were working with it.

So what I did was to say, when we do the US GAAP taxonomy, we should take out from the taxonomy all the stuff that's oriented toward that presentation problem and put it over into a separate module, which at the time we called Mixed XBRL. This was kind of an early prototype that actually used XBRL itself in a strange way but the basic idea of using HTML syntax was central.

But then, the folks from DecisionSoft and CoreFiling, who  are just tremendous XML experts in our community and have done tremendous work for us, refined that notion and said, “We can actually take this one step further, and make it even better by saying let's not try and reinvent presentation at all, let's just embed the XBRL directly into HTML.” They put a huge amount of voluntary work into the specification and into making that work; that specification is actually now in its last call for public comments and will soon in fact become a recommendation.

So what I would say is that if I had been working with DecisionSoft directly from the outset around this time last year we probably could have gotten to the whole thing faster. I still think Inline XBRL has a key role to play.

(11) You are one of the true pioneers of XBRL and have played a major role in its development almost since its inception. As you look back over the past several years, has the pace of XBRL reception been about what you had expected? Have there been any major surprises for you in the nature and pace of XBRL adoption, either positively or negatively?

It sounds strange to say but I actually think we're about where I expected to be and that is just because as a software engineer I understand that you make project plans… and then “stuff happens.”  The stuff that happens hardly ever makes things go faster.

Mark Schnitzer, he is now with Microsoft, told us in 1999 that it was going to be about ten years before XBRL was mandatory for all filers in the US. That was a heluva good prediction. In some sense, I think that that's about the right pace.

I guess the thing that really has surprised me -- and once again I will admit it as a younger person in 1999 I really didn't understand it – was a political point, and that is, how differently other countries view their government. I didn't realize that there were other countries where people trusted their own government a lot more than we do. I think the Dutch, the Japanese, the French, the Spanish, I think they trust their government more than Americans, and so consequently they can move faster. I think in other countries it's going to go more slowly.

The other thing I was very surprised at was that the investor relations community, the people who are responsible for selling their company's story, have not been a lot more active. I am mystified by it and I think it just has to do with the fact that the software is still not quite there to make it easy for them.

I don't think they're the kind of people who are comfortable kind of hacking the code and looking at the angle brackets. But it is surprising to me that you don't find companies that specialize in building investor relations websites doing much more with XBRL. It surprises me, because I think there's a big value proposition for companies in participating in XBRL development and being on the leading edge.

I don't think there are many people who get into IR from the software side. They’re professional writers, financial people.

Agreed. You look at what that culture is, and it is about language and communication, it's not about the data. But if you look at Microsoft's Investor Central, I think that’s a great example of what can be done. My point is that I expected it to be done around 2003 not 2007. It's not a disappointment, I just didn't understand that part of the world at all. I do think that the investor relations groups need to go look at sites like Investor Central and think about what they could be doing with fundamental data and linking it to supporting detail, or portions of the analyst briefings, or other material that would be so much more effective.

 

0

Why Was the XBRL Introduction in Japan Successful?

Written by Bob Schneider
Posted on July 1, 2008 Comments
July 1, 2008 | General | Bob Schneider

Written by Toshinori Kobayashi     Posted on July 1, 2008

Toshinori Kobayashi is director for enforcement of corporate disclosure at JFSA, the Financial Services Agency of Japan. He was responsible for the XBRL renovation project of EDINET, the JFSA’s electronic disclosure system. In his previous articles, Toshinori offered a brief introduction to adopting XBRL for EDINET and described the JFSA's voluntary filing program.  In this post, he discusses why he thinks the implementation of XBRL in Japan went smoothly. 

Last November, when SEC Chairman Christopher Cox met in Japan with the Financial Service Agency’s (FSA) cabinet minister and managers, he asked about the EDINET renovation project. Specifically, the Chairman wanted to know how the implementation of mandatory XBRL filings had proceeded so well.

We discussed the details of our experience with him.  The new EDINET system requires some 5,000 listed companies and 3,000 funds to submit their financial reports in the XBRL format. So far, we've heard few voices of protest or dissatisfaction. How was EDINET able to introduce the new reporting regime so smoothly?

First of all, when we originally began discussing incorporating XBRL into the EDINET system, the act of making XBRL statements mandatory beginning in fiscal 2008 was not a fait accompli. Starting in 2004, several reports were issued on the project through March 2006, but these reports didn't clearly touch upon the issue of making XBRL mandatory.

For me personally, since becoming the EDINET project leader in July 2006, I was uncertain about the mandate issue for six months or more. I thought that XBRL reports offered a useful tool for high-level analysis for investors. Whatever the timing, I didn't doubt that making XBRL mandatory was a necessity. But could implementing a mandate in one fell swoop beginning in 2008 be done smoothly?  How do you go about starting with a successful voluntary program and run it for some time, and then switch over to making XBRL mandatory on all fronts?

This confusion was symbolized in what was being written about the project. During the time the renovation project was underway, there were two articles in major Japanese newspapers about introducing XBRL. The first was on November 15, 2006; the second on June 10, 2007. The 2006 article said that "Depending on the spread of the use of XBRL, the FSA is looking at making it mandatory for reporting companies.” An accompanying chart in the article said that XBRL would be implemented under "a voluntary system." In other words, the 2006 article implied that the new EDINET would be launched as a voluntary XBRL system at first, and then the FSA would consider the transition to a mandatory system. Clearly the mention of a "voluntary system" was misreported, but the fact was that in the interview I didn't say that beginning in 2008 the program would be mandatory.  By contrast, in the June 2007 article, the headline said "mandatory."

In the second half of 2006, XBRL still wasn't well-known in Japan. Would filers' cognizance of XBRL and their preparations be sufficient by 2008 for an interactive data mandate? Would they be able to absorb the costs for moving to XBRL? Beginning in autumn 2006, there were several months to sweep away the confusion surrounding these questions and decide whether or not the go-ahead should be given for mandatory XBRL filings in 2008.

During this time, the FSA was explaining the issues regarding the transition to XBRL to those affected by a mandate and inviting them into discussions.  At this point, we did not discuss macro policy issues such as whether XBRL should be mandated. Rather, our discussions were conducted on a practical level to come up with workable solutions for the various problems an XBRL mandate would create. Our talks were aimed at dispelling the psychological resistance and anxiety that users would feel upon introduction of the new system, and sharing practical information about the move to XBRL with users and other key stakeholders .

The primary vehicle for moving the discussion forward and accomplishing these goals was the Working Group (WG) of the EDINET Advancement Council. This WG was initiated when the decision to introduce XBRL was initially made, but had been inactive for about a year; it was reorganized again for the next level of discussions.  Its members were key players in the business world: the Keidanren, which represents Japan’s major industry leaders; the Securities Analysts Association of Japan; the Japan Securities Dealers Association; the Japanese Institute of Certified Public Accountants, or JICPA (which includes all CPAs and auditors); the Financial Accounting Standards Foundation (the accounting rules-making body); the various stock exchanges (the Tokyo Stock Exchange, the Osaka Stock Exchange, JASDAQ); the Bank of Japan (which had already introduced XBRL and whose cooperation was very important); and the National Tax Agency.

Besides all the key stakeholder representatives, XBRL Japan and the financial printing companies (mentioned in my previous post) also participated as observers. From October 2006 to February 2007, the WG debated important technical and technological issues, including the selection of accounts under the EDINET taxonomy and related user issues; the display method for XBRL data; and formats (with the introduction of XBRL filings, formats would be different from those existing under HTML). Concurrent with the general activities of the WG, there were active discussions of specific issues with members knowledgeable about those problems. The WG’s work and discussions were forwarded to individual members of the participating organizations, the representatives of which take part in the WG.

Of course, it was impossible to exchange views with all of the 5,000 companies and 3,000 funds that would submit XBRL filings. But as a vehicle for airing and debating the issues, the WG functioned as a window through which its member organizations, companies, and other interested parties could efficiently exchange information and have their voices heard. (And to be frank, I also think it was a way to justify that the FSA could pursue debate with valid representatives of the various stakeholders involved.)

Also, individual discussions were held with the associations of 23 industry sectors for which separate taxonomies needed to be prepared, taking into consideration the particular accounting rules for the specific industry (banking, utilities, insurance, construction, etc.).  Information was exchanged and opinion was solicited also from the relevant government agencies (such as METI; the Ministry of Land, Infrastructure, Transport and Tourism; and others).

We requested the members of the Working Group and the industry associations and government agencies of the 23 sector groups to review their respective taxonomies from a real-world perspective to ensure they were viable. At the same time, from January to February 2007, the first pilot program was conducted with about 50 of the filing companies testing the taxonomies. Based on the results, upgraded versions of the taxonomies were prepared. 

Regarding user costs for XBRL implementation, our major concern was the expense of the software tools for the filing entities. In 2006, Japan’s software market did not offer XBRL tools with good cost performance, and for a period of time, the FSA looked at providing software with minimum functionality at no cost to users. But discussions with software vendors revealed that they were planning to develop and make available to users good XBRL software tools at low cost by 2008.  In addition, we were informed by the printing companies (which more than 90% of reporting entities use) that they plan to offer XBRL filing services at a cost not significantly higher than that for HTML statements.

Through a concentrated six-month effort, we were able to take a fresh approach to the issues raised by an XBRL mandate and became confident with the solution we developed by the time the renovated EDINET system started up operations in 2008. Through improved relations with stakeholders, information was provided to them on the changes that would be introduced by XBRL filings and the essentials for preparation. These efforts served to heighten stakeholder recognition about the new system and was extremely effective in enlisting the cooperation of the business community.

With no indication of broad opposition to the goal of introducing XBRL by 2008, the FSA became confident that sweeping changes that incorporated XBRL into the new EDINET system could be put into place this year. In a speech I gave at a symposium in March 2007 sponsored by XBRL Japan, the JICPA, and the TSE, I said for the first time that "XBRL filings would be made mandatory from the time the renovated EDINET system was put into operation."  That was the start of the FSA beginning to make an aggressive appeal through various media for a mandate, and, as I described in my previous post , that was the environment in which the second pilot program proceeded.

There was yet one more decision that had to be made regarding the mandate: the timeline for submission of financial reports in XBRL format.

The new XBRL-enabled EDINET system would be inaugurated on March 17, 2008; at the beginning of April it was possible to require that financial statements be filed in XBRL. Because the vast majority of Japanese companies have a March fiscal year-end, the most recent yearly financial reports were for March 2008 and would be filed in June.  We had to consider whether the XBRL mandate would apply for March 2008 yearly reports. Within the FSA, there were those that championed "mandate XBRL from fiscal years ending in 2008"; with the systems now in place, requiring XBRL for the vast amount of yearly reports for March 2008 would well symbolize the renewal of the EDINET system.

However, as a result of our discussions with the business community, we understood that the June date for submission of March 2008 reports made for a tight schedule. Indeed, there was a lot of sentiment that it would lead to chaos (this was the only issue where companies had a truly negative reaction during the whole XBRL project).  Because quarterly reports have relatively few disclosure items, the burden of kicking off the XBRL mandate with three-month statements was not heavy. This viewpoint prevailed, and the mandate for XBRL filings began with reports for companies' fiscal first quarter of 2008.

Looking back, I think there were two major “keys for success” in the smooth XBRL implementation in Japan: close cooperation with the stakeholders and the timing. Our method of gradually formulating consensus through a conversation with the business community may be uniquely Japanese. It also helps that Japan’s corporate culture is relatively accepting of unilateral regulations. In any event, I think creating an environment that focused on the stakeholders, and making sure key players recognized the significance of the interactive data mandate and were well prepared for the changes that it would impose, were both essential to the smooth introduction of Japan’s XBRL mandate.