XBRL News and Commentary from the Hitachi XBRL Business Unit
0

XBRL: Short-Term Costs Will Yield Long-Term Benefits – Part I

Written by Bob Schneider
Posted on February 16, 2007 Comments
February 16, 2007 | General | Bob Schneider

Written by Bob Schneider      Posted February 16, 2007

Events this decade have been so dramatic that it's hard to recall it began with prospects of a Y2K meltdown. Billions of dollars were poured into correcting the ancient code that expressed years in overly economical double-digits. The Y2K effort was naturally focused on avoiding catastrophe and not on any ancillary benefits. But after January 1, 2000, came and went without major incident some charging the fears had been overblown, others that the huge Y2K investment had saved the day technology officers began to contemplate the resulting gains.

Inventory-taking of software and systems that was once done haphazardly, if at all, was standardized. Systems for communicating software issues, both within the organization and to customers and suppliers, were upgraded. Formal software audit policies were introduced. Rules for contingency and disaster planning were detailed and prescribed.

The return on Y2K investment grew dramatically in the wake of 9/11. When the terrorists attacked, the redundancy built into information systems in the event of a Y2K meltdown proved highly advantageous. The global banks headquartered in lower Manhattan were able to shift with relative ease to the backup systems that had been enhanced through Y2K outlays. The Northeast Blackout of 2003 provided additional evidence of the efficacy of Y2K expenditures, with the relatively rapid restoration of power in many areas because of Y2K capital investment.

Just as the country was recovering from 9/11, the series of business scandals symbolized by Enron came to the forefront. In the wake of corporate deceit, the Sarbanes-Oxley Act (SOX) was passed in 2002. In my post XBRL Dovetails Nicely with SOX's Surprising Benefits, I discussed the Harvard Business Review article that enumerated the unexpected gains from the law. These included strengthening the overall internal control environment and exploiting convergence opportunities from other regulatory requirements. Although I wouldn't declare that the view of SOX in Corporate America is now widely positive, I think it's fair to say that many organizations have become resigned to the law and are now focusing on ways to leverage their SOX investment.

Now CFOs may face another significant challenge: a mandate by the SEC that public companies file their financial reports in XBRL. Such a requirement would be far different in both scope and character than either Y2K or SOX. It would not be a response to an imminent threat of systems meltdown or to a loss of confidence due to corporate chicanery. Rather, it would be an effort to improve upon existing methods of financial reporting that, all things considered, have worked fairly well. And the resources expended would be far below those for Y2K and SOX.

Nevertheless, since more than a few firms will view the cost/benefit equation from an XBRL mandate to be mostly cost and little benefit, it's important to consider whether there are likely to be longer-term positives from their outlays for XBRL. In other words, do public firms have reason to believe that, like Y2K and SOX, they will be able to leverage their XBRL investment?

In the second part of this post, scheduled for publication on February 23, I will discuss why I think the return on complying with an SEC mandate for XBRL financial reporting may be better than many companies now believe.

0

In Pursuit of Process

Written by Bob Schneider
Posted on February 13, 2007 Comments
February 13, 2007 | General | Bob Schneider

Written by David vun Kannon    Posted February 13, 2007

David vun Kannon was one of the first Co-Chairs of the XBRL Specification Working Group and has been an Editor of every version of the XBRL Specification. He is a Director for PricewaterhouseCoopers, LLP.

In my previous post, I talked about using XBRL linkbases to represent the many kinds of relationships found in segmental reporting. In this entry, I'd like to take that idea in another direction namely, business modeling.

Typical segment reporting might look at the performance of a business unit from just a few common points of view, such as a geographic or product breakdown. But if we try to analyze a business at fine levels of detail, we eventually have to leave behind a view based on organizational units, and begin to look at the business processes taking place within an organizational unit. This is especially true if we want to understand the business at the level of what parts of the business contribute to the values reported on financial statements.

As an example, consider a large bank. You might find that a bank holding company (in the US) owns several bank operating companies. Each bank operating company might have branches spread across several states. So far, this is just a description at the classic unit and geographic levels.

If we look within one of the branches, we see a variety of business processes. For example, tellers and ATMs interact with customers, collecting and receiving cash. Loan officers discuss loans and approve funding. Each of these processes has a different effect on the financial statements of a company, whether those statements are summarized at a level for external reporting, or at the granularity of management reporting.

There are several high level models of the processes of a business. One is the Process Classification Framework available from http://www.globalbestpractices.com/ (Global Best Practices is a trademark of PricewaterhouseCoopers, LLP, my employer). Another such framework is available as part of the COSO materials. COSO, which stands for Committee of Sponsoring Organizations (of the Treadway Commission), is an organization which has developed a set of materials to help businesses understand and control their processes more effectively.

The COSO framework for internal control has become very well known in recent years. The passage of the Sarbanes-Oxley legislation in the US required companies to report on the quality of their internal control environment, and identify the framework the company is using to organize their documentation of internal control. Many companies have chosen the COSO framework for that purpose.

It is, of course, possible to extend the high level COSO process hierarchy with more company specific subprocesses. This process hierarchy is easy to map into the form of an XBRL taxonomy, just as the other hierarchies we have already seen.

A possible objection to using XBRL in this way is that there are other XML vocabularies that have been developed specifically for the purpose of business process modeling. These vocabularies include XPDL, BPML, and BPEL.

Indeed, if I were trying to document a business process at a very operational level of detail, one or another of these languages would probably be much more appropriate to use than XBRL! However, our purpose here is just to name the processes and show their general relations, not dive into the details of each process. In fact, it would be appropriate to link the process elements in the taxonomy to process descriptions in one of these vocabularies, if they were available.

Another reason to continue in XBRL is that there is so much more to add to a business process model that is not covered by the BPM specific languages. COSO and other frameworks attach nonprocess concepts to process descriptions, concepts such as objective, risk, and control. While there is no obvious way to model or document a business risk in a process modeling language, we can easily extend our hierarchy in XBRL with more abstract elements that represent the objectives of a process, the risks that may prevent those objectives from being achieved, and the controls that are put in place to mitigate the identified risks.

Here is an abbreviated example hierarchy, showing how different kinds of abstract objects are related to each other:

Bank Holding Company
--(owns)  Bank Operating Company A
--(owns)  Bank Operating Company B

Bank Operating Company B
--(operates)  Branch 1
--(operates)  Branch 2

Branch 2
--(performs)  Cash Operations
--(performs)  Loan Operations

Cash Operations
--(composed-of)  Collect Cash Deposits
--(composed-of)  Disburse Cash

Collect Cash Deposits
--(achieves)  Available for Use
--(achieves)  Safeguard Customer Funds

Available for Use
--(imperiled-by)  Employee Theft

Employee Theft
--(mitigated-by)  Videotape of Workplace
--(mitigated-by)  Working in Pairs
--(mitigated-by)  Hiring Practices

That's enough for this post. What we've shown is that it is possible to use XBRL to develop a unified set of hierarchies that allow us to drill down into a business from the highest level to very granular descriptions of its processes. While this amount of detail is becoming familiar to American business, most companies have not yet moved to holding it in a neutral, flexible format like XBRL. It is at best scattered across the organization, and locked up in several incompatible formats.

0

XBRL and the Telegraph Code Book

Written by Bob Schneider
Posted on February 9, 2007 Comments
February 9, 2007 | General | Bob Schneider

Written by Bob Schneider     Posted February 9, 2007

The laying of transatlantic cable in the second half of the 19th century revolutionized communications between the US and Europe. But the resulting telegraphy could hardly be described as instant messaging. It was not until the 20th century that speeds reached even 120 words a minute. Moreover, cabling was extremely expensive. It cost a quarter to send a single word from New York to London in 1900, a lot of money back then.

To pack more information into a message, senders and receivers employed code dictionaries of phrases and other expressions. The sender would find a phrase with his intended meaning and include the accompanying code in his message. (For example, in one code book, caninero stood for "have ceased selling" one word standing for three.) The code message would be transmitted by the telegraph or cable company. The recipient would look up the code words in another copy of the same book or follow other procedures to find their meaning.

Thousands of code books were created. The most popular was the all-purpose ABC Code (which went through seven editions between 1873 and 1936). There were also books for specific industries and segments, with terms useful for a particular trade. Some books were sold to the general public; others were developed by individual firms for their own use and remained proprietary. The codes particularly the specialized codes arranged their phrases by topic, sometimes in tables, to save space and facilitate message coding. (If you'd like to know more about the code books, take a look at Jim Reeds's fine introduction, or at the material and extracts assembled by my friend John McVey at his site.)

I'm hesitant to compare 21st century XBRL with a 19th century technology. Still, I do see direct parallels. The code books are analogous to XBRL taxonomies, the vocabularies or dictionaries that provide the foundation for information exchange. The telegraph transmission can be compared to the instance document, a file that contains content structured in the XBRL language. Whoever deciphers the cable's meaning does the work of the XBRL reader, which can access, view, and analyze an instance document.

The levels of specificity reflected in code books from all-purpose ABC Code to, say, Acme Inc. Code also yield rough equivalents in the taxonomy hierarchy. If we consider XBRL for financial reporting alone, ABC Code corresponds to the Commercial and Industrial taxonomy for US GAAP. Industry code books are aligned with industry taxonomies, eg, that for oil and gas. The 19th century firm had its own company code book; the 21st century firm has its own company XBRL taxonomy.

Then as now, competition for "standards" existed. As John writes: "The codes competed on various mixes of convenience, depth and/or breadth, error-resistance, reputation of compiler, novel system, even naturalness of their expressions (for the so-called "verbatim" codes)." Old books and systems were discarded as better ones were created, while others remained to complement the new works. Today we see XBRL competing with other XML-based standards (RIXML, FIX, MDDL, etc.) for broad-based recognition and acceptance, but also at times working in collaboration.

I don't pretend that there are any great lessons in comparing highly elaborate XBRL with the relatively straightforward telegraph code book, which in the end are dissimilar communication tools, introduced in business and regulatory environments separated by 150 years. But I do think it helps to put the challenges XBRL faces in perspective. It informs us, once again, that technology adoption is a process, where competition and collaboration work in tandem to respond to user needs.

2

A Memo to XBRL-US

Written by Bob Schneider
Posted on February 6, 2007 Comments
February 6, 2007 | General | Bob Schneider

Written by Christopher Whalen     Posted February 6, 2007

Richard Christopher Whalen is Senior Vice President and a Managing Director of Institutional Risk Analytics (IRA) with responsibility for sales, marketing and business development. Chris is a general securities principal and has worked as an investment banker, research analyst, and journalist for more than two decades.

We are frequently asked why we take a contrarian, sometimes critical view on XBRL, yet remain committed to making this standard for business reporting a reality. The answer is very simple: we can see the value of XBRL in many aspects of data collection, transmission, and delivery, but not all of these business cases have the same strength or urgency.

When we look at the question of achieving the universal adoption of XBRL, we are reminded of a saying in the technology world: The task is possible, but very difficult. This is particularly the case when a well-intentioned group of technologists, who are mostly driven by a transformational vision of how the future of business reporting could or even should look, attempts to impose sudden, comprehensive change on the business professionals who are responsible for the day-to-day workings of the commercial data world.

From a purely theoretical perspective, XBRL makes enormous sense. For example, XBRL organizes and characterizes data, and makes it interoperable. Yet each of these benefits is not necessarily as strong as the other, especially when viewed from the perspective of the business case needs of a decision maker whose main criteria for selecting one technology over another is short-term cost.

In order for XBRL to win broad adoption in the marketplace, we believe that the proponents and vendors alike need to ask themselves some basic questions. The answers to these queries, when applied to the business case needs of real live customers, will help those leading the effort at XBRL-US make efficient choices about where to deploy scarce resources.

First, if you observe the data pipeline and divide the steps that data must travel between the point of creation and end-user consumption, it quickly becomes clear that some parts of the XBRL business case are more compelling than others.

In the case of the FDIC, for example, the data collection and validation tasks are clearly a big winner and have saved that agency enormous amounts of money and man hours in terms of collecting financial statement data from US banks. The accuracy of the data and the reduced time and personnel resources needed to collect and validate it are business case wins that make their own arguments.

Yet in conversations with regulators at the FDIC and other agencies, we find little enthusiasm for pushing the XBRL model down through the entire data delivery pipeline to end users. In fact, most federal regulators seem satisfied with the cost savings and data accuracy wins achieved by using XBRL at the top of the data pipeline.

When asked whether they intend to store or distribute the data in XBRL, the answer is no; the data will be decomposed into its constituent parts, processed and stored using legacy database systems, distributed to examiners and analysts via these same legacy systems, and consumed using existing tools such as Microsoft Excel. Much the same response comes from end users in the investment world who are aware of the XBRL adoption effort.

Indeed, as XBRL-US moves forward with its adoption activities, we predict that the powerful business case arguments in favor of the technology at the start of the data pipeline -- namely, organization, collection, and validation -- will become more and more prominent in discussions, while the end-use rationales so popular with many downstream vendors will fade. This is not because there are no downstream benefits to XBRL, but because these business case arguments, in relative terms, are not yet mature enough and powerful enough to withstand the critical scrutiny of business case needs.

In fact, if you leave aside the unique example of the SEC's voluntary filer program and look instead to the numerous potential opportunities for adoption by other public sector entities, the importance of the upstream benefits of XBRL becomes even more pronounced. Thinking about examples like automating financial reporting between the various federal agencies or between Washington and state and local agencies, there are a plentitude of obvious areas where XBRL could be employed to great benefit.

But again, the sales process by proponents of XBRL adoption need go no farther than organizing, collecting, and validating the data. These benefits are very powerful and are more than sufficient to win over those public sector constituencies that XBRL-US needs to convert into soldiers in the campaign for adoption. If XBRL-US takes this lesson and focuses on winning the adoption battle step by step, with the most compelling applications first, then the XBRL adoption process will result in success.

0

Relationships Matter

Written by Bob Schneider
Posted on January 30, 2007 Comments
January 30, 2007 | General | Bob Schneider

Written by David vun Kannon     Posted January 30, 2007

David vun Kannon was one of the first Co-Chairs of the XBRL Specification Working Group and has been an Editor of every version of the XBRL Specification. He is a Director for PricewaterhouseCoopers, LLP.

In my previous post on entities in XBRL, I covered a difficult issue: how to bring together data on the same entity that comes from different sources which use different naming schemes. XBRL taxonomies and linkbases were the answer. In this post, I'd like to expand on the idea of using XBRL taxonomies to represent business entities.

One of the main tasks in business reporting is to report on parts of an entity in other words, segmental reporting. The segments can be operating subsidiaries, geographic regions, or product lines. Segmental reporting is a part of external reporting to the capital markets and market regulators, and it is even more important internally to the management of a business.

In contrast to the previous issue of identity management, segmental reporting is driven by the issue of relationship management. However, it shares the same solution, namely, XBRL linkbases.

Just as we used abstract elements to represent business entities for identity management, we can extend that idea to cover segments of a business. A recent recommendation from XBRL International named XBRL Dimensional Taxonomies (XDT) provides the basic solution.

XDT is a complex specification for reporting segmental breakdowns of incredible complexity. For our purposes here, we don't need more than the basic idea of a dimension, built from a domain and domain members. A dimension can represent an entire segmental hierarchy for reporting. Several different dimensions can represent the many different hierarchies that businesses need and use regularly.

XBRL linkbases also allow the relations to vary in a hierarchy. In a common XBRL linkbase, such as the presentation linkbase or calculation linkbase, only one arc role is used to create the entire network of relations. In the presentation linkbase, this is the parent-child arc role. In the calculation linkbase, it is the summation-item arc role.

As an extensible specification, XBRL allows us to create our own arc roles for use in our taxonomies. (It also encourages users to reuse arc roles invented by other people through the Link Role Registry. Let's hold that aside for another post!) An example of that kind of custom arc role was the "identified-by" arc role shown in my previous post.

With custom arc roles, we can make the relationships of our business entities as specific as we want. For example, we can use "owns", but we can also use "majority-owns", "controls-management", "joint-venture", "investment-company-complex", or any other specific relation that meets our business modeling needs.

The tools of XDT and custom arc roles allow us to craft linkbases that connect the abstract elements which represent business entities. These linkbases are then part of the entire taxonomy of an enterprise, something that has been discussed for a long time within XBRL circles as the entity map.

An entity map is a powerful example of master data management. It resides outside of any specific application, in contrast to the consolidation hierarchies of some financial reporting tools. It can be managed and maintained as a separate unit of corporate intellectual property of value to dashboards, financial reporting and consolidation, and external reporting.

In the case of an entity map, the relations are as important as the objects they relate. That makes XBRL a good modeling choice when relationships matter.

0

XBRL Blogs and Forums

Written by Bob Schneider
Posted on January 26, 2007 Comments
January 26, 2007 | General | Bob Schneider

Written by Bob Schneider     Posted January 26, 2007

In my last two posts, I described (mostly) online sources that approach XBRL from a business (rather than technological) point of view. My XBRL Reading List detailed writers and publications well worth looking at. In Presentations at the Philadelphia Conference, I mentioned several of the most useful speeches and articles from the December meeting, among the many that have been posted online.

In this post I'll talk about blogs and public forums that are either dedicated to XBRL, or at least discuss XBRL-related topics from time to time. One of the great challenges to widespread XBRL adoption is that most people outside the XBRL community still don't know what it is. In spreading the word, XBRL blogs and forums have an important role to play. Some of these venues are likely familiar to you, but I hope I've found a couple that will be new.

The blog of the IR Web Report regularly has articles on XBRL. In the past few weeks there have been stories about Canada's recent inauguration of a voluntary XBRL pilot program and the launch of the SEC's XBRL tool. The articles are usually authored by Dominic Jones, who has long experience in the investor relations field, particularly in Canada.

Another leading XBRL blog from our northern neighbor is the XBRL Canada Blog. The focus, naturally enough, is XBRL developments in Canada; but blogger Gerald Trites, a Project Director of XBRL Canada, has useful comments on other topics as well (full disclosure: he did post a positive comment about Data Interactive about a month ago). Mr. Trites has been a Professor of Accounting and Information Systems at St. Francis Xavier University in Nova Scotia, and a partner at KPMG.

Jack Ciesielski at the AAO Weblog doesn't write about XBRL that often, but when he does write he has interesting things to say. Ciesielski is both a CFA and CPA who has long experience as an analyst of accounting issues.

CFO.com, which I have previously recommended for its longer articles on XBRL, also discusses XBRL issues in its CFO Blog. The posts are listed in The Skinny On XBRL box in its XBRL: You Can't Ignore It Anymore collection of links.

Fund r2 was just launched this month, but it already looks promising. Blogger Max Rottersman, who says he has been analyzing funds for 17 years, is just the kind of writer XBRL needs, ie, an experienced investment pro eager to tackle highly technical financial issues and explain them in everyday terms. In XBRL: eXperts Business Reporting Language, Rottersman describes how XBRL combines both aspects of databases and traditional documents, and elaborates on how this mixture causes problems for XBRL adoption.

Shifting from blogs to groups, the public forums for discussing XBRL issues are not thriving. The main reason is that most discussion of XBRL issues has now moved to the Listserv and Sharepoint groups of XBRL.org. These so-called e-Groups can only be accessed by consortium members. The XBRL groups on Yahoo, which formerly provided a venue for debate, are now mostly dormant. XBRL-Public, with 1,200 members, is the largest, but new messages only average a couple every week. XBRL-COREP and XBRL-FINREP, which center on European developments, tend to be the most active. There is little activity at Google Groups.

Have I left out any important blogs and forums readers should know about? Please use the Comments section below or email me and let me know.

0

Open Source and XBRL

Written by Bob Schneider
Posted on January 23, 2007 Comments
January 23, 2007 | General | Bob Schneider

Written by Brian DeLacey    Posted January 23, 2007

Brian DeLacey is the Founder of Interactive Securities. He has worked on mainframes, minicomputers, and PCs since the dawn of the digital era. Mr. DeLacey worked at Lotus Development and IBM for 13 years, and on research involving information technology and the adoption of new technologies at the Harvard Business School for eight years. He can be contacted by email.

How do you make money from something that is free? That could be the key business question of the early 21st century.

Open source software has roots in the establishment of open standards which served as the guiding principles of the early internet. The U.S. Government established the Advanced Research Projects Agency (ARPA) in 1958 and increasingly sponsored information technology research in the 1960s and 1970s. The fundamental work from these programs grew into a widely used platform for shared communication in the 1980s known as the internet. This, of course, provided the communications infrastructure for the phenomenal launch of the World Wide Web in the 1990s. (More history and the anticipated future of open source can be found at the website of NetAction.)

There are numerous legal and practical definitions of what free and/or open source software is. In general, it refers to software that is intellectual property, is available for your use in source code and/or binary form, and requires no advance purchase or payment. There are a number of organizations providing more details and precise definitions on these aspects of open source (there are a multitude of licensing options). Two expert organizations are The Free Software Foundation (FSF) and The Open Source Initiative (OSI).

A recent study from the United Nations University estimated that free and open source software could represent 32% of all IT services in the EU, and 4% of the entire European GDP, by 2010. Open source is thus truly a technological earthquake with aftershocks affecting not only the methodologies and processes developers follow in creating software, but also the business models supporting a customer's use of software. Harvard Business School Professor Marco Iansiti and co-author Gregory L. Richards recently released a working paper titled The Business of Free Software: Enterprise Incentives, Investment, and Motivation in the Open Source Community. (An interview with the authors is also available online.) This would be an excellent place to begin a detailed search on learning more about the business of free and open source software.

In June 2006, in response to a call for open comment from the SEC, I submitted a letter expressing hope that open source would play a role in the move toward interactive data. Two leading companies recently announced plans to provide their XBRL engines as open source. Rivet Software announced plans to release their XBRL Viewer as open source in early 2007. (Rivet's software, which is being developed under contract to the SEC, enables investors to view XBRL documents residing on the SEC's website.) UBmatrix released an open source version of their XBRL processing engine on January 9, 2007.

The same guiding principles which fueled the amazing growth of the internet are now at work in the domain of application and systems software development. In sum, open source represents a fundamental wave of change that's well worth paying close attention to and becoming actively involved in.

3

Presentations from the Philadelphia Conference

Written by Bob Schneider
Posted on January 19, 2007 Comments
January 19, 2007 | General | Bob Schneider

Written by Bob Schneider Posted January 19, 2007

The 14th International XBRL Conference was held in Philadelphia in early December. I did not attend, and press reports were spotty, so I was curious to find out more about what went on. Many of the presentations are now available online, about 60 in total. Most are PowerPoint slides, which can be very useful for attendees who recall the speaker's narration and those familiar with the material. But I have to admit that, for me, viewing slides can be like watching TV with the sound off okay for a Heat-Lakers game, but more often like watching a quiescent Laverne and Shirley.

It appears, though, that full text for most of the speeches of the plenary sessions are available, and some of those for the various tracks as well. I have gone through these, and several are well worth your time. As always, if you think I've skipped over any presentation worth mentioning, please let me know. (By the way, if you were a presenter and would like to use this space to describe or expand upon your Philadelphia talk, please contact me -- I'd be delighted to publish your post.)

The keynote address of SEC Chairman Christopher Cox was, pardon my New Yorkese, a real humdinger. In the Philadelphia setting, his battle cry of "no taxonomies without documentation" had special urgency. Mr. Cox's speech ranged widely but coherently, touching upon the improvements that XBRL offers users, his recognition of the crucial role played by the private sector in XBRL adoption, and the impact of interactive data on the audit process, One revealing stat he cited was that only about 5% of accounting restatements were due to deliberate errors, while over half are attributable to misapplication of basic accounting rules. Chairman Cox believes XBRL will be an enormous help in eliminating these errors.

Ian Ball, Chief Executive of the International Federation of Accountants, discussed how XBRL enhances credibility at each link of the information supply chain, which includes (1) management, (2) auditors, (3) regulators, creditors, and reporting agencies, and (4) users. The advantages he cited for the auditing profession seemed particularly salient (well, at least for this former auditor):

"More importantly, however, the current manual data mining can be replaced by more timely, accurate and complete data for analysis of all types. Simple balance sheet statistical sampling efforts, for example, can be replaced by 100% validation routines, or by deeper analysis of ledger-level data. XBRL will permit more effective analysis of data for anomalies greater access and lower cost access to data from ledgers enables the more effective analysis of large data pools for anomalies of fraud, compliance and other forms of audit assessments."

Those remarks are followed up in the accompanying The Impact on Assurance, New Challenges For The Audit Profession. The paper discusses various scenarios where XBRL will be used, including the conversion of traditional statements to XBRL as well as the case where the XBRL statements are the primary statements. Principal author Gerald Trites of XBRL Canada helpfully includes a good deal of background on the reporting process and on XBRL, so it's useful for a broad range of readers.

A good complement to this discussion is Kuo-hua Chou's presentation How Valid Are They?. In essence, Mr. Chou performs a reality check on claims of infallibility for calculations in XBRL statements. In examining XBRL Voluntary Filing Documents with the SEC EDGAR System, Mr. Chou validated 93 instance documents against their discoverable taxonomy sets and found a significant number of inconsistencies. "All these inconsistent instances have calculation errors," Mr. Chou writes. In describing his findings, Mr. Chou also provides significant background about XBRL and XML.

Jeff Diermeier, President & CEO of the CFA Institute, discussed the help XBRL affords investors in terms of transparency and accuracy. He warned, however, of rushing the process of taxonomy creation. Specifically, he was cool on the SEC's target date of summer 2007 for taxonomy completion, since he believes it "increases the risk of delivering an end product which does not meet the expectations" of users.

Finally, the comments of Sir David Tweedie, Chairman of the International Accounting Standards Board (IASB), on standardizing global accounting principles are extremely useful. He spoke about interaction of (a) the development of XBRL taxonomies and (b) the convergence process between IFRSs and US GAAP, with its target date of 2009. He stated, that to the extent that US GAAP and IFRSs are converging, so should the XBRL taxonomies. He also noted the important commitment of the FASB and the IASB to make continued progress in other areas where accounting practices under both sets of principles require improvement.

0

The Entity Problem

Written by Bob Schneider
Posted on January 16, 2007 Comments
January 16, 2007 | General | Bob Schneider

Written by David vun Kannon     Posted January 16, 2007

David vun Kannon was one of the first Co-Chairs of the XBRL Specification Working Group and has been an Editor of every version of the XBRL Specification. He is a Director for PricewaterhouseCoopers, LLP.

In my blog post last week, I discussed in general how XBRL could be applied to problems in Master Data (metadata) Management. In this post, I'd like to focus on the problem of MDM for business entities.

XBRL assumes that entities exist, and are one of the fundamental objects about which people want to know facts. That is why entity is a necessary part of the context for every fact in an XBRL instance document. On the other hand, facts that don't apply to an entity (or apply to all entities) are bad matches to XBRL. How, for example, should the value of pi be represented in XBRL?

XBRL also assumes that all entities can be named, somehow, but doesn't create or force the use of a particular naming scheme. There are many naming systems for entities, and the instance author can choose the most appropriate one. The SEC assigns CIK numbers to companies for filing purposes; the FFIEC variously uses RSSD IDs, Cert numbers, and OCC charter numbers. Dun and Bradstreet creates DUNS numbers.

All very nice, but what happens when I want to combine XBRL data from a 10-K, a call report, and a credit report for the same bank? The combined instance documents don't contain any clue that this CIK, that Cert, and that DUNS number all refer to the same legal entity.

This is a problem that I call the identity management problem in XBRL. It crops up in many industries, such as KYC (Know Your Customer) rules in banking. I suffer my personal version of the problem because my name has an unusual spelling, and many people or computers assume I don't know how to spell my own name. Mail arriving at my home is addressed frequently to Mr Vun, Mr Kannon, Mr Vonkannon, Mr Vukahaho you get the picture. Direct mail advertisers must think a small militia has encamped on my property.

This problem of multiple identities in different schemes is an error when it comes to junk mail. But if I were a bank (BankDavid, the friendly bank) it would be an unavoidable fact of life.

XBRL taxonomies to the rescue. We can define an abstract element that represents the legal entity BankDavid, and associate to that abstraction the identifiers used in multiple different identification schemes, such as the CIK, Cert, and DUNS.

image001.gif

This kind of linkbase could be shoehorned into the standard XBRL reference linkbase, but it is probably more appropriate to separate this data out into a separate kind of linkbase (a use of the generic linkbase concept).

As a data pattern, this is the classic hub and spoke model. Adding a new identifier magnifies the value of all previously linked identifiers an example of Metcalfe's Law.

As an example of the problems of metadata management, we only need a few thousand elements to capture all the publicly traded companies in the US. This is similar in scale to the set of financial reporting concepts in the US GAAP taxonomy well within the scale of XBRL implementations. In comparison, it is vastly smaller than the smallest data warehouse is designed for.

0

My XBRL Reading List

Written by Bob Schneider
Posted on January 12, 2007 Comments
January 12, 2007 | General | Bob Schneider

Written by Bob Schneider     Posted January 12, 2007

Robert Bork, in his hearings to become a Supreme Court justice, apparently doomed his candidacy by saying he regarded the position as an "intellectual feast" (presumably, he was supposed to say "a golden opportunity to help working families across America").

But I'm certain I'll suffer no harsh reprisals by expressing a similar joy at being editor of Data Interactive. XBRL is an intriguing topic on so many levels -- technological, financial, political that one of the job's great pleasures is simply reading what smart people have to say about it.

In this vein, I offer some suggestions of who and what to read on XBRL. I know many readers will finish this post and wonder why I left out this person or that journal. The most likely reason is either ignorance or oversight, so please add a comment or email me and I'll post your suggestions. In my recommendations, I have tried to include articles that are either on the Internet or can be easily accessed from databases like InfoTrac OneFile that are available from the websites of large public libraries.

First, let me put in a word for the guest bloggers Data Interactive has published to date, including (in alphabetical order) Gianluca Garbellotto, David vun Kannon ("Why Is XBRL So Hard?", Strategic Finance, August 2004), Gary Purnhagen, and Mike Willis. I find anything written by them interesting, informative, useful.

Next, at the risk of appearing sycophantic, I strongly recommend the speeches of SEC Chairman Christopher Cox and Chief Technology Officer Corey Booth. Their presentations are always thoughtful and well-written, and they provide insight on where these important decision-makers believe XBRL is headed.

Neal Hannon is one of the best and most prolific writers on XBRL, particularly on its many and robust uses beyond financial reporting. His articles appear regularly in Strategic Finance, and the IMA's Suggested Reading page has links to many of his pieces.

CFO.com consistently offers high-quality, informative articles. Take a look at XBRL You Can't Ignore it Anymore, which has links to their recent pieces on interactive data.

Eric Cohen has a long history of making accounting technology topics interesting to readers, as his piece on "Interactive Data and the Tax Executive" (Tax Executive, May 1, 2006) demonstrates. And Christopher Whalen, head of Institutional Risk Analytics, has important things to say about XBRL, by no always favorable.

Other authors well worth reading are Mark O'Connor (see his XBRL are we close to the tipping point? in CMA Management), and Maria Trombly, whose work often appears in Securities Industry News. Interviews with XBRL luminaries such as Charles Hoffman and Walter Hamscher are certainly worth your time too.

While not the work of a single individual, I should mention the XBRL Educational Resources Center at Bryant College. It is an extremely useful page with loads of links to articles, news, tutorials, etc. Of special note is an index of XBRL articles from 2000- to mid-2006.

Of course, some of the best commentary on XBRL now takes place in blogs and on forums, and I will address these venues in a separate post. Again, I encourage you to add a comment or send me your suggestions of articles that should be on everyone's XBRL reading list.

0

Master Data Management the XBRL Way

Written by Bob Schneider
Posted on January 9, 2007 Comments
January 9, 2007 | General | Bob Schneider

Written by David vun Kannon     Posted January 9, 2007

David vun Kannon was one of the first Co-Chairs of the XBRL Specification Working Group and has been an Editor of every version of the XBRL Specification. He is a Director for PricewaterhouseCoopers, LLP.

Master Data Management (MDM) has acquired a certain buzzword status in the last year or so. MDM is the recognition that there are critical corporate assets -- such as customer lists, which often exist as data embedded in an application -- that need management as a separate and distinct entity. This may be necessary for simple data consistency across platforms, or it may be a legal mandate.

One aspect of MDM is that several applications, or instances of the same application, have to share and synchronize metadata. Another is that this metadata has to be thought of as a distinct corporate asset that needs maintenance, just like a building or factory needs maintenance.

You may have noticed that I've already made a shift from master data to metadata. This is intentional. I'd like to leave behind the somewhat over-hip buzzword, and reframe the issues in terms of a larger context. That context metadata sharing and maintenance is one where I think XBRL can play a role in successful projects.

It's Data Warehouses All the Way Down

In the same spirit as generals always fighting the last war, many approaches to MDM focus on using data warehouse (DW) technology to address the metadata sharing problems of an organization. This often results in layers of data warehouses paralleling the organization of the business.

While this approach may be comfortable or familiar to IT staffs and the vendors that love them, it is not always appropriate.

First, consider that data warehouses were designed to handle extremely large numbers of transactions (data), and only secondarily the metadata necessary to support those transactions. The MDM problem is not a fire hose of billions of transactions that must be stored in one place so that they may be analyzed. Instead, MDM involves a few thousand to a few million rows of data that must be shared quickly across many applications and locations. DW fits MDM like a square peg fits a round hole.

Second, MDM is as often as much about the structure and relations of objects as it is about the objects themselves. Suppose you get an email: "Quick, send me your complete chart of corporate organization, including relations of ownership, management control, cross investment, directors and managers who hold multiple positions, tax domicile, etc, etc., etc."

Do you have a Brazilian subsidiary with greater than 50% foreign ownership, but management that is wholly or majority Brazilian? How fast can you answer the question? Can you answer before the regulator in Brazil fines your company? Is paying the fine cheaper than answering the question?

OK, by now you are crying for a metadata sharing solution that can capture the objects and relations (including business rules) of your master data and is cheap to implement, standards based, and easy to share with regulators around the world. And you know I have the answer to that cry XBRL.

This kind of metadata sharing is right in the sweet spot of XBRL. As mentioned in my post of several days ago XBRL: Living Up to Its Name, it's what made the FFIEC implementation of XBRL a success. This shouldn't come as a surprise. MDM is a problem of data transport and standardization of metadata. XBRL is a standard that operates at the data transport layer. Round peg, round hole.

0

XBRL: A Data Standard for a Globalized Economy

Written by Bob Schneider
Posted on January 5, 2007 Comments
January 5, 2007 | General | Bob Schneider

Written by Bob Schneider     Posted January 5, 2007

When I was working as an editor in Japan in the 1980s, the big buzz word was kokusaika, or internationalization. Twenty years on, globalization is the word that's all in vogue. And just as new communication technologies (like fax) facilitated internationalization in the 1980s, the innovative XBRL data standard will be key to globalization.

In the popular imagination, I don't know if internationalization and globalization are easily distinguished. But at least for people who follow these trends, there is a substantial difference:

"Internationalization refers to the increasing importance of international trade, international relations, treaties, alliances, etc. The basic unit remains the nation, even as relations among nations become increasingly necessary and important. Globalization refers to global economic integration of many formerly national economies into one global economy, mainly by free trade and free capital mobility, but also by easy or uncontrolled migration. It is the effective erasure of national boundaries for economic purposes."

Just like internationalization, which I would throw into a report when I couldn't think of anything else to say, globalization has become a buzzword bordering on clich, for economic populists and management gurus alike. The thing about clich's, though, is that they become clich's for a reason, i.e., they were repeated over and over because they are particularly descriptive and useful and, at one point, original and interesting.

Even if many of us wish the now-tired globalization would just go away, its enormous impact will continue to be felt in the decades ahead. I was reminded of this by two articles I recently read, one by Michael Mandel in Business Week and the other by Anatole Kaletsky in the Times (London).

Mandel's focus was the US; Kaletsky's was Japan. Mandel emphasized how globalization has impaired the ability of U.S. political institutions to effect economic change. Kaletsky emphasized how globalization has upended traditional macroeconomic assumptions about the economic competitiveness of strong manufacturing nations like Japan.

But both pieces reinforced the point that globalization is having a profound impact on nations, companies, and individuals. As these various entities compete in a globalized economy, what strategies can they adopt to be winners in the new environment?

Although it may be mere happenstance, perhaps it isn't surprising that in 2004 China -- the nation we associate most with globalization -- became the first country to mandate that all of its listed companies file its financial reports in XBRL. Other countries that depend importantly on overseas markets, such as Spain and the Netherlands, have also been leaders in XBRL adoption for financial statements.

But as readers of this blog are well aware, the potential of XBRL extends far beyond financial reporting. As Gianluca Garbellotto wrote in his recent post on this blog:

"Data archival, data integration, consolidation, auditing and compliance, generation of various internal and external final reports from the same underlying transactions, and automation of the related reconciliations are only some of the processes that XBRL can help make more efficient."

Many of these processes will be important for the success of the global company. But it is improved data integration that I think will be particularly crucial. Even Chinese companies are now moving production facilities offshore, as they seek the optimum set of conditions for costs and logistics. Combining information from external and internal sources -- in various jurisdictions and across functional lines -- is a task at for which XBRL-GL is peculiarly suited. As XBRL moves beyond its traditional boundaries of financial reporting to business reporting for the entire organization, companies will realize the return on their XBRL investment, thereby inspiring a virtuous cycle of increased outlays and greater diffusion.

None of this is to discount the substantial roadblocks along the way in XBRL becoming the global business reporting standard. But it's essential that this larger vision of interactive data be kept in mind as efforts to adopt XBRL for financial reporting continue. Just as internationalization has given sway to globalization, the current emphasis on XBRL for global financial reporting should eventually yield the spotlight to its general use for a broad spectrum of information needs for the global company.

0

XBRL: Living Up to Its Name

Written by Bob Schneider
Posted on January 2, 2007 Comments
January 2, 2007 | General | Bob Schneider

Written by David vun Kannon     Posted January 2, 2007

David vun Kannon was one of the first Co-Chairs of the XBRL Specification Working Group and has been an Editor of every version of the XBRL Specification. He is a Director for PricewaterhouseCoopers, LLP.

For many people, interactive data is too difficult to say, so we invented the simpler term XBRL. Not!

OK, I've been involved in XBRL long enough that the acronym trips off the tongue. But what does it mean? Right, eXtensible Business Reporting Language. That's a language just for 10-Ks and Call Reports, right? Wrong!

XBRL should live up to its name: it's not financial reporting, but business reporting. There is enormous untapped potential for XBRL still to be realized, which is hinted at by the difference between business and financial reporting.

Let me make two arguments for this. The first is revealed by a typical magic quadrant diagram. In one quadrant is financial, numeric data (eg, assets = $724,632 ). This is the sweet spot of XBRL today. Next is financial, non-numeric data. This is less common, but could include text paragraphs or specific concepts (bond rating = Baa).

In the non-financial, numeric quadrant is operational data (electricity produced = 700 megawatts). The Enhanced Business Reporting initiative, the Global Reporting Initiative, other kinds of �triple bottom line, and management-targeted KPI-based dashboards can use XBRL in this way.

The final quadrant is non-financial, non-numeric. My favorite example of this kind of data is the assessment of an internal control -- is it effective, ineffective, significantly or materially weak, or is it untested? The important commonality is that all of the above are business measurements that can be taken of an entity at a point in time or over a duration. That makes them fair game for representation in XBRL.

Now the previous examples are of (in XBRL jargon) instance data. If separation of duties for cash disbursements was ineffective on Dec 31, 2005 is an instance fact, what is the taxonomy?

This leads me to my second point: sharing the metadata is often more important than sharing the data. So a big opportunity for XBRL is organizing pools of metadata in ways that can be exploited for further data sharing. Here is an example. The implementation of XBRL in the FFIECs Call Report Modernization project is justifiably well known as a successful use of XBRL. (Full disclosure I was involved in Phase I of the project.) What was the big innovation (IMHO) provided by XBRL that made it a success?

It wasn't the ability to transfer data in an electronic format (ie, the instance document). The FFIEC already had a format for electronic data transfer. Instead, the big win was upgrading the metadata so that it could be understood and used by banks (and their supporting software vendors) more easily. Using XBRL taxonomies, and including a formula linkbase to represent validation rules and sanity checks, to share metadata was the real innovation. It was the enabler of the other breakthroughs, such as self-checking by the bank before the call report is sent.

These areas of business reporting non-financial reporting and metadata sharing are huge opportunities for XBRL to be applied to new problems. As people become accustomed to XBRL for financial data, I hope to see a growing awareness of what can be done elsewhere.

1

Adaptation or Evolution: What Is Your XBRL Strategy?

Written by Bob Schneider
Posted on December 8, 2006 Comments
December 8, 2006 | General | Bob Schneider

Written by Gianluca Garbellotto Posted on December 8, 2006

Gianluca Garbellotto is a member of the XBRL Standards Board and an active participant in various XBRL Working Groups. He is a frequent and sought-out presenter on XBRL and XBRL GL topics, as well as the XBRL columnist for IMA's Strategic Finance magazine.

XBRL is here. It's not just a matter of growing interest, or more frequent discussions on upcoming implementations. XBRL is required for regulatory reporting in many countries, including the U.S. (in the case of banks), and many others are well on their way to mandating it. Certainly the major investments in this technology recently announced by the SEC cannot be only aimed at adding one more format to the many already available for filings.

Every major company needs a strategy for XBRL. There's no doubt that the major incentive for XBRL adoption comes from regulators that mandate it. This is obviously a great way for a technology to gain momentum; but it's also, in my opinion, the greatest challenge that XBRL faces. There are two ways in which companies (and other entities) can react to a mandated adoption. One is adaptation, the other is evolution.

Adaptation here means doing what is strictly necessary to fulfill the regulatory requirement, either using internal resources or through outsourcing. Most likely, the regulatory filing will be generated in the same format as before, and then it will be converted to XBRL using the original filing as a source. This approach seems appealing because it minimizes short-term implementation costs. However, a closer look may reveal unsuspected indirect costs, especially as XBRL mandatory filings become more numerous over time. To advocates of XBRL like me, adaptation represents a lost opportunity.

Evolution is the more effective approach in a changing environment. In this case, it requires two important actions by corporate management:

1. Understanding XBRL's true value proposition, beyond its more visible and familiar implementations; and
2. Conceiving a strategy that does fulfill the short-term regulatory requirements; but, at the same time, leverages the power of this very targeted and effective standard for business and financial data for purposes much beyond regulatory reporting.

Here is the challenge. The value proposition of XBRL for regulators, analysts, and entities in general that collect, process, and compare data from a large number of sources is evident, and that's why the adoption of XBRL is originating in the regulatory sphere. Individual filers do not currently see benefits for themselves in this process; they tend to think that XBRL is just another format for representing data, no different than a CSV or PDF file, but much more difficult to implement. (Of course, XBRL enthusiasts can relate the potential benefits of more transparent end reporting, as well as the new benefits that XBRL GL, the standardized Global Ledger, can bring, where end reporting can become a simple by-product of internal processes improved by XBRL.) And all this just to make life easier for regulators and analysts! Limiting the analysis to XBRL's most visible application can easily lead to underestimating its real potential.

XBRL for financial and regulatory reporting (XBRL FR) is a powerful and flexible technology to represent summarized information in internal and external end reports. XBRL GL is an agreement on how to use the XBRL technology to represent business and financial data at the detail/document level in a standard, consistent format, no matter in which application or jurisdiction it was generated or resides in. These two different faces of XBRL can be used separately or they can interact with each other. They not only broaden the value proposition of XBRL as a whole much beyond financial, let alone regulatory, reporting. They also offer the opportunity to change the way in which many crucial business processes are dealt with in a corporate environment.

Data archival, data integration, consolidation, auditing and compliance, generation of various internal and external final reports from the same underlying transactions, and automation of the related reconciliations are only some of the processes that XBRL can help make more efficient. It is the ideal payload for SOA (Web Services Oriented Architecture). Being a standard, both a technical format and more importantly in the semantic representation of documents and transactions, it makes seamless exchange of data and information within a business and between information-trading partners (not only regulators, but also auditors, and business partners in general) a reality.

XBRL is the key to a new, standards-based, cost-effective, vendor-independent way to deal with many crucial processes in every corporate environment. A comprehensive XBRL strategy can help your company turn a regulatory burden into a competitive advantage.

0

The Name Game: XBRL or Interactive Data?

Written by Bob Schneider
Posted on December 5, 2006 Comments
December 5, 2006 | General | Bob Schneider

Written by Bob Schneider     Posted December 5, 2006

In our recent post on Tim Bray's embrace of XBRL, we did not mention the interesting, if less crucial, point he made on nomenclature. Specifically, Tim prefers the four-letter XBRL acronym to the phrase "interactive data" espoused by SEC Commissioner Chris Cox. Although Tim sympathizes with the need to re-brand XBRL for a wider audience, he leaves the impression that interactive data doesn't quite make it as a synonym.

We sympathize greatly with anyone who attempts to create a compelling brand name for a complex technology like XBRL. Our own attempts at rechristening yielded only eXtremely BRiLliant data, which is hardly descriptive or revealing.

We do have some doubts about interactive data as a synonym for XBRL. Don't get us wrong. We're fully on board with the powerful argument for XBRL adoption as a means of making data easier to access, manipulate, and integrate. We believe it will make data more transparent, current, and actionable. But we're less sure if XBRL is notably more "interactive" than some other data formats, or that interactive data is uniquely descriptive of XBRL.

At the same time, even if interactive data is not completely explanatory, its look and feel seem right. The adjective "interactive" implies integration, actionable, dynamic and other good things that XBRL promises.

The two-word phrase offers other advantages. Unlike the seemingly random four-letter acronym, interactive data is reasonably distinctive. You pretty much have to be a software developer to distinguish XBRL from XBEL and KMEL (in case you're wondering, the last two represent Bookmark Exchange Language and the call letters of San Francisco's hip-hop radio station). To the rest of us, XBRL is just four floating letters in the alphabet soup of computer terms.

Moreover, interactive has a positive connotation and associations who doesn't want to be active, and interactive at that? It's not the easiest term to remember, but certainly simpler than a seemingly random four-letter text string. Interactive data also sounds appropriate to task and function, if a little geeky and technical.

Advertisers and marketers place enormous emphasis on the power of names, and that certainly goes for the public policy arena as well as the private sector. Examples abound: Would a "death tax" by any other name sound so abominable? Certainly not if it's called an estate tax. And whatever the pluses and minuses of building a missile defense system, surely its path would be smoother had it not been dubbed Star Wars early on.

The upshot is that interactive data provides in reasonably plain English a useful alternative to another impenetrable four-letter acronym. For anyone schooled in the tradition that you should never repeat the same word twice in a sentence, interactive data is a godsend. If you still hear the voice of your ninth-grade English teacher telling you to vary your language in every sentence, you are deeply appreciative of a widely acknowledged synonym for XBRL. The overriding objective is to make XBRL widely known among financial and business information users, and interactive data is up to the task.

0

Don’t Overstate the Benefits of XBRL

Written by Bob Schneider
Posted on December 2, 2006 Comments
December 2, 2006 | General | Bob Schneider

Written by Bob Schneider Posted December 2, 2006

Tim Bray is Director of Web Technologies at Sun Microsystems who writes the highly regarded Ongoing weblog. He is a recent convert to the interactive data cause, and it's enormously exciting to have him cheerleading for XBRL.

Tim's posts can present a major problem to his fellow bloggers, however, because in a single sentence he can be so interesting and provocative that it would require ten posts to respond adequately. Take this gem:

"A certain part of the deep complexity and abstraction in accounting theory is in fact there to reflect business reality; but I'm convinced that another part of it is there to serve as a carpet under which to sweep inconvenient truths."

Where to begin? The inability of the 19th century accounting model to deal with 21st century enterprises? The shortcomings of short-term, market-driven quarterly statements? The many constituencies, ranging from small investors to huge government agencies, that financial statements must serve? The difference between the heavy-on-the-rules U.S. accounting and the more holistic approach of the Europeans? There's subject matter here for not just ten posts, but ten books.

Tim's deft one-liner on GAAP comes from Transparent Business, a post he wrote after attending a meeting with Chairman Cox and others on interactive data. In the article he waxes enthusiastic about XBRL and how it will make company data transparent to readers of financial statements. In fact, in my view he is a little too enthusiastic and overstates the case for XBRL.

For example, Tim says that corporate websites currently provide just the "basics" on companies, like "where the offices are, who the CEO is." He strongly implies that little financial information is available online and that interactive data will come along and change all that. But most websites of companies now have respectable investor relations sections that include their annual reports and links to recent SEC filings. And in any case, the filings can all be found and read at the SEC's EDGAR site.

Maybe Tim was just exaggerating to make a point, since the IR section of his own Sun Microsystems is loaded with investor data. But here what's important: I think he's too optimistic about the potential of XBRL for eliminating the creative accounting that some companies employ to mislead. Certainly XBRL has significant potential for making internal controls more rigorous, which should lead to an overall improvement in the quality of financial statements. But remember, XBRL is just a data standard, not a cure-all for accounting's many problems. To burden it with the heavy load of eliminating all financial shenanigans especially when a penny or two difference in per-share profits can wallop a company's stock price -- is unreasonable, even unfair, and can only lead to disappointment among financial statement users.

If a footnote is written with the intent to obfuscate rather than enlighten, it will remain confusing whether it's coded in XBRL or not. If an accounting issue becomes a political football that gets kicked around among Congress, auditors, and CFOs until its stitching unravels, XBRL isn't going to patch things up. A central weakness of GAAP that it combines data like bank balances that are known to the penny and estimates like pension costs that are educated guesses at best will not be resolved by XBRL.

Despite my disagreement with Tim on the extent to which XBRL will make financial data transparent, it's wonderful to have him on the interactive data team. The support of executives like Tim who command widespread respect in all sectors of the business community will ease the path toward XBRL adoption.

UPDATE: After re-reading this post, I realize I should have made important mention of the ability of XBRL to implement real-time reporting of company results, as well as the recent report of the CEOs of the major audit networks, which calls for a new reporting model that takes advantage of interactive data's capabilities. Both developments have the potential to make major changes in the nature of financial reporting.

At the same time, real-time reporting of certain financial and nonfinancial data won't eliminate the need for periodic financial statements, and discussions about overhauling the traditional accounting model have been going on for decades. The overwhelming difficulties of making financial results easily comparable among all companies of all nations will remain. XBRL can help ameliorate those problems, but it shouldn't be expected to extinguish them.

0

Highlights from the NYSSA’s 13th Annual Finance Reporting Conference

Written by Bob Schneider
Posted on November 28, 2006 Comments
November 28, 2006 | General | Bob Schneider

Written by Yuki Ozawa     Posted November 28, 2006

Yuki Ozawa, System Engineering Manager at Hitachi America, Ltd., recently attended the annual financial reporting conference of the New York Society of Security Analysts and filed this report:

This NYSSA conference spotlighted a number of financial reporting issues and the critical role XBRL can play. Even when interactive data was not the specific topic of discussion, its potential impact and usefulness were easily seen. Of special note were the following sessions:

Scott Taub, Deputy Chief Accountant of the SEC, briefly updated the audience on the benefits, issues, and current activities concerning XBRL. He highlighted the SEC's recent allocation of $5.5 million for the development of taxonomies. A roadmap to international convergence was also discussed, and Scott noted SEC activities to support International Financial Reporting Standards (IFRS). Scott introduced the subject of restatements, a key topic that was addressed several times during the conference.

Eric Linder, Principal at SavaNet, looked at XBRL from the vantage point of a financial analyst with a view toward implementation. Eric discussed several recent XBRL developments at the SEC, and he raised issues concerning the Commission's XBRL reporting program for end-users like investors and analysts. One important focus of his discussion was that, although companies are required to use certain taxonomies under the US-FRTF framework, they have wide-ranging ability to extend those taxonomies and add new items. As a result, the largest problem today is inconsistently structured and non-comparable items.

Given my own experience working with XBRL, I had much sympathy for Eric's viewpoint. XBRL can bring tremendous benefits as a standard language for financial information; nevertheless, versatility remains an important concern. To reap the greatest benefits from XBRL, there's a need to refine existing business processes first. Eric also mentioned his recommendations for current SEC approaches, which he titled the SEC Three Step XBRL Program. The steps are (1) create XBRL reporting program implementation rules, which address basic analytical needs; (2) update Regulation S-X for present-day practices of electronic reporting; and (3) be directly and intimately involved in the taxonomy development process.

Kevin J. Cameron, President of Glass, Lewis & Co. gave a talk titled When Will the Restatements Stop? In this session, Kevin reviewed the current circumstances surrounding restatements. He noted that restatements have been increasing and, if current trends are stable, there will be more restatements in 2006 than the 1,200 reported in 2005. Kevin described how restatements can affect a company's stock price and offered several examples. He provided statistics on the numbers of restatements, broken down by industry, company size, quarter, the reasons for errors, and other measures. Thus, his audience gained an understanding of which companies tended to make restatements and the reasons for them. In my view, in some error categories XBRL can definitely help avoid restatement, but it's unrealistic to think that many restatements can be eliminated simply by using XBRL. Further investigation and analysis are necessary to detect the causes of restatements, and reporting and validation processes should be improved at the same time.

Near the end of the day, Elmer Huh, Senior Vice President of Lehman Brothers presented Stock Options: Too Much of A Good Thing? Elmer's discussion focused on the difficultly analysts face in forecasting the impact and assessing the real cost of stock options. It seemed to fit in squarely with one of the overarching themes of the day, namely, the complexity of the many issues raised by attempting to present meaningful, transparent, actionable financial data for highly diverse companies to highly diverse audiences.

NOTE: The complete agenda of the conference is available online.

0

XBRL Cuts Costs by Enhancing Supply Chain Processes

Written by Bob Schneider
Posted on October 14, 2006 Comments
October 14, 2006 | General | Bob Schneider

Written by Mike Willis    Posted October 14th, 2006

Mike Willis served as the Founding Chairman of XBRL International. He is a partner with PricewaterhouseCoopers and has more than 24 years of accounting experience.

One day, while discussing shareholder communications with a client, I proposed they consider reporting in a new Internet language format for their annual and quarterly reports. My initial argument was that this new language would increase the visibility of their reports and therefore was good for shareholders. Management countered that they mailed their reports to all shareholders and were not convinced of the transparency argument. As a result, I asked "how much does it cost to print and mail all of your reports to shareholders?" The answer: "$750,000 annually."

Finally!! A concept that any accountant can understand: cost reduction.

We agreed that publishing company annual and quarterly reports on the company web site in the new language -- which, as you may have guessed, was HTML -- would save them printing and mailing costs. But that was over 10 years ago. What does that have to do with XBRL The message is the same, except that the impact is more pervasive across a broader range of compliance processes and the cost savings are larger.

XBRL is designed to enhance recurring supply chain processes including access, validation, analysis, and reporting, regardless of whether they occur at the investor, regulator, corporate controller, or corporate operational levels. XBRL provides a software application agnostic platform to describe business information and critical relationships, thereby enabling the information to be more efficiently transferred, managed, validated, analyzed, and reported across the diverse set of software applications used by enterprises and their stakeholders.

How significant are the cost savings that a company might expect? It depends on the current degree of manual controls and interfaces applied to process business information as it moves across, between, and around the disparate applications. You can assess this by looking closely at your own processes to determine the level of:

(1) Manual information access points. Spreadsheet templates are a typical indicator;
(2) Manual validation efforts. Typically the responsibility of the user rather than the preparer, and often occurring at the data warehouse;
(3) Manual analytical and business rules. Often hard-coded within disparate software applications (e.g. a spreadsheet macro) requiring significant resources to manage, audit, and/or change;
(4) Manual compliance quality control assessment processes. Performed repeatedly for each and every report;
(5) Time and resources applied to these process areas.

The benefits realized are a continuation of the cost savings generated by HTML a decade ago -- except they are now focused on business information and are thereby more pervasive across the full range of supply chain processes, and not just printing and delivery. To determine if XBRL might be useful to your company, assess your current processes closely for manual interfaces, manual process steps, and manual controls. There may be more opportunity for cost reduction than you think.

1

XBRL-GL Can Work with ERP for Data Integration

Written by Bob Schneider
Posted on October 9, 2006 Comments
October 9, 2006 | General | Bob Schneider

Written by Bob Schneider    Posted October 9, 2006

There are two varieties of interactive data. One is XBRL for Financial Reporting (XBRL-FR), which is used to express the summary information found in financial statements and has only a limited amount of detail.

The other is XBRL-GL, which was designed to represent any data item that that can be reported through a general ledger. XBRL-GL can detail data and documents, including accounting entries, trial balances, payroll info, receivables and payables, inventories, statistical indicators, and more. It can bring together data from disparate operational, reporting, and accounting systems and consolidate it through Web Services, high bandwidth networks, and petabyte storage systems. It is therefore ideal for system integration, consolidation, data migration, and data archiving.

In the interactive data world, most of the focus thus far has been on XBRL-FR; but within the organization, XBRL-GL will be of much greater relevance. Traditional management accounting, with its emphasis on the allocation of costs among company functions, tends to erect walls between departments that create information silos. The adoption of XBRL-GL can break down the barriers in function-based organizations and enable data integration. As the emphasis of management accounting shifts to the analysis of business processes and workflows throughout the organization, the role of cost accountants is being transformed. Rather than focus on cost allocation, the emphasis will be on analyzing the firm's business processes to ensure the timely flow of quality information necessary for effective operations.

Moreover, XBRL-GL is one of the pillars of Next-Generation Architecture which, coupled with Web Services and Service-Oriented Architecture (SOA), allows data to perform multiple business reporting tasks, both within and outside the organization. Potentially, anyone will be able to access, edit, and validate data wherever it resides and from whatever application it came from.

Can ERP systems, as they are now constituted, offer similar results? ERP is essentially a closed system that does not work well in this kind of distributed environment where data from different systems serves users both within and outside the entity. Even in high-level ERP systems, there tends to be "spreadsheet sprawl" and other operational tools that require manual integration. XBRL, in contrast, integrates information systems to serve both internal and external users.

It should be emphasized that XBRL is simply a data standard, and thus interactive data itself is not a replacement for the infrastructure of ERP systems. But XBRL can be used successfully both in conjunction with ERP and as a means for implementing ERP alternatives.

0

The Green Eye Shades Come Off

Written by Bob Schneider
Posted on October 9, 2006 Comments
October 9, 2006 | General | Bob Schneider

Written by Bob Schneider    Posted October 9, 2006

The current impetus to adopt XBRL is improved financial reporting. The extraordinary advantages of interactive data for government agencies, stock exchanges, and other regulatory bodies are encouraging them to adopt XBRL for their reporting requirements. In their effort to implement XBRL as a data standard, they should be supported by a host of financial statement users -- ranging from security analysts to small investors -- who will enjoy the benefits of real-time reports and easy data manipulation that XBRL offers.

But the potential of XBRL extends far beyond financial reporting. The flexibility of XBRL-enabled data makes it similarly desirable for everyday use throughout the organization in areas like manufacturing, procurement, and human resources. The reach of XBRL beyond the financial realm will be strongly supported by crucial business needs.

One such need is internal control. Sarbanes-Oxley (SOX) now requires that management state in its annual report its responsibility for maintaining an adequate system of internal control. According to the definition provided by the COSO framework, which the SEC suggests for SOX compliance, internal control encompasses the effectiveness and efficiency of operations, reliability of financial reporting, and compliance with applicable laws and regulations.

While SOX specifically limits internal control to financial reporting, for independent auditors the line isn't so easily drawn. For practicing CPAs, all three parts of the COSO definition are vital to their attest function. Absent a sound system of internal control that includes all three definitions, auditors would have to review a stunning number of transactions to ensure the integrity of financial statements. By necessity, internal controls need to be implemented on a companywide basis, and they are greatly facilitated by the easy interchange of data that XBRL offers.

Another trend that leans heavily toward XBRL adoption is the increasing integration of business activities among different companies and business entities. These associations range from supplier relationships to tie-ups and, at the top of the integration scale, to mergers and acquisitions. The ability to exchange data is a key ingredient in combining business activities. As businesses push to optimize efficiency, there is a need for a data standard that makes the exchange of information easy and seamless. While remaining vigilant about the security exposure such openness entails, companies will be eager to adopt XBRL because of the advantages it affords in data interchange.

Moreover, as globalization proceeds, companies want to be able to optimize their use of resources both human and nonhuman -- wherever they are located. Thus XBRL fulfills the need for a data medium that clears the barriers presented by different tongues and business cultures.

The full-scale implementation of XBRL as a universal data standard remains several years away. But the spread of interactive data to everyday business activities is inevitable.

← previous1...910111213141516next →