Written by Peter Boritz     Posted on December 22, 2009

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

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

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

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

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

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

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

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

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

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

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

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

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

Written by Peter Boritz     Posted on December 14, 2009

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Written by Sunir Kapoor    Posted on December 7, 2009

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

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

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

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

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

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

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

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

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

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

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

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

Written by Peter Boritz     Posted on December 3, 2009

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

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

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

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

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

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

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

Written by Bob Schneider    Posted on December 3, 2009

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

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

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

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

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

Here are some parts I especially appreciated:

Syntax Is Not Enough (pp. 41-47)

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

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

Explaining XBRL at the Water Cooler (49-52)

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

Creating and Using XBRL (Chapter 15)

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

Differentiating XBRL Modules (Chapter 16)

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

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

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

A Thought Experiment (330-33)

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

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

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

Specific Uses for XBRL (353-355)

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

Keys to Understanding How XBRL Works (369-376)

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

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

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

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

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

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

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

It is a major achievement. Buy the book.