Written by Bob Schneider     Posted on January 23, 2010  

For 20-plus years, I have struggled to learn Japanese. A primary challenge has been to remember some 2,000 characters Japan imported from China. Because they derive from ideograms (ie, graphic symbols of ideas), like many students, I have tried to remember the character by looking for the graphical elements of meaning still present within it.

Good luck with that. Among the many reasons this approach is (mostly) unhelpful is that – almost from the beginning — characters were sometimes miscopied, corrupting and confusing the meaning elements within them.

Of course, East Asian characters do not have a monopoly on transcription issues. Numerous scholars are devoted to textual criticism of the Greek classics, seeking to identify, interpret, and remove copying errors. It’s not hard to conjecture some reasons for the mistakes – hard-to-read handwriting, the distraction of a comely Grecian walking past, a scribe with his own agenda going rogue (or at least introducing small variations).

I mention these events of antiquity because ever since computers entered the office, people have been blaming them for screwing things up.  (Film buffs will recall how EMERAC, brainchild of IT consultant Spencer Tracy, fired the CEO at Katherine Hepburn’s company in the 1956 movie Desk Set.) But it’s not the mechanical, automated workings of the computer that are at fault. It’s the manual processes requiring human input and intervention that gum up the works.  

We were sadly reminded of this fact by the misspelling of Umar Farouk Abdulmutallab, the Christmas bombing suspect, in a State Department database. A correct entry may not have prevented the incident, but we do know his name appeared on some government lists and not on others. Certainly the failure to uniquely identify this individual in the government’s information systems points to the utility of “enter once, use many” data entry that minimizes human intervention.

The need for consistency and accuracy in names pertains as well to government financial reporting. Rekeying of financial data is not only costly and time-consuming, but it introduces the same sorts of error and inconsistency that manual processes always engender. Three years ago I discussed the report Transforming Financial Information: Use of XBRL in Federal Financial Management. In describing the benefits of consistency that XBRL would bring to Federal budgeting formulation and execution, the report states:

Having a single XBRL based window for the transfer of information would also eliminate a number of reconciliation points, since budget request submissions and reports would be created from the same underlying data with no manual intervention. XBRL would ensure consistency across all agency financial review reports and reduce the reconciliation burden of the recipients such as FMS, OMB, GAO, and Congress. The transition of the closing package data from PDF or Excel to XBRL would also address cost issues imposed on FMS by receiving reports from agencies that use inconsistent terminology and rules of classification. XBRL would allow all agency recipient entities to utilize a standard vocabulary for all closing package reports.

I can’t find evidence that any progress has been made in introducing XBRL to the Federal budgeting process in the past three years. There has been the recent push to have public companies receiving government bailout funds to use XBRL to report how they spent the money. The bill passed the House with bipartisan support on December 14, and it is included in a larger Senate bill renewing the Federal Financial Assistance Management Improvement Act (FFAMIA). According to a January 5 report in Compliance Week, both branches of Congress have approved versions of the bill, and only minor differences remain to be reconciled before obtaining the President’s signature.

Coupled with the SEC’s XBRL mandate, the Federal government appears to be making significant progress in having companies provide data in XBRL; but it has made less headway in introducing the data standard to its own financial reporting systems. As the bipartisan sponsorship on renewing the FFAMIA indicates, this seems at least one area of public policy that might not descend into political squabbling, and where the benefits of eliminating manual processes in information systems can be obtained.

Written by Peter Boritz     Posted on January 11, 2010

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. Part 3 looked at filing issues in several areas, including taxonomy extensions, negated facts, consistency checks, fact checking, filing path, per share information, and decimals. In this final post, I focus on the detail tagging of footnotes that the SEC mandate requires for companies in their second year of filing XBRL statements.

Technically speaking, detail tagging is a cross mapping of disclosure facts to a reportable element pertaining to the disclosure and any elements that are the subject of the disclosure. These disclosure facts apply to concepts described within the narrative. For example, a disclosure relating to inventory policy may map to both the policies disclosure element and an element for inventory. A detail tag applies to numeric facts within disclosures and refers to elements to which numeric facts pertain.

To put it bluntly, detail tagging is a lot of work. Beginning with the second year of the SEC’s phase-in of XBRL, these requirements are mandated for company financials:

•    Each complete disclosure is tagged as a single block of text
•    Each significant policy within a policy disclosure is tagged as a single block of text.
•    Each table within each disclosure is tagged as a separate block of text.
•    And within each disclosure, each numeric fact (monetary values and percentages) must also be detail tagged.

Detail tagging becomes easier if detail tags map to single paragraphs. Managing disclosures by paragraph provides greater control and better possibilities for detail tagging and compartmentalized analytical searching. Because a detail tag applies to a specific subject (as a written paragraph does, or at least should), you would expect zero-to-one detail tags per paragraph. But this is not necessarily true: a specific paragraph may detail tag to more than one element.

In essence, a detail tag is an XBRL footnote. For each disclosure block, you are creating a footnote to an external element to which the disclosure also pertains. Handled manually, this can be extremely time consuming. In the old days before computer compilers, people would tediously take Fortran code and convert it into assembler. It took a technician to back up a programmer. Similarly, today we have detail tag technicians who manually create footnotes based on detail tagging instructions provided by reporting managers. It does not have to be this way. A good software product should allow you to drag and drop an element onto a disclosure block to create a detail tag. That’s it — no additional effort should be required.

Detail tagging is a difficult process and requires professional proficiency to achieve the quality of cross tagging required. There are over 16,000 elements in the US-GAAP taxonomy. For each text-based data fact, the question arises as to if and how to detail tag. Detail tagging requires human effort and prudence regardless of the best efforts of your software.

Consider the following examples taken from a presentation on detail tagging at the 2009 XBRL US National Conference held in November:

Derivatives
The fair value hedge has a notional amount of $250 million, and hedges approximately 86% of the $292 million of outstanding senior notes maturing in September 2011. The estimated fair value of the contract at September 30, 2009, was $3.5 million.

The possible detail tags may include the following elements:
•    NotationalAmountOfInterestRateFairValueHedgeDerivitives
•    PercentageOfDebtHedgedByInterestRateDerivitives
•    SeniorNotes
•    InterestRateFairValueHedgeAssetAtFairValue

There is obviously a fair amount of skill required by a reporting manager to make the above determination. However, in terms of accountability, there is little the SEC can do to insure the degree of quality required by the above declarations.
 
Income Taxes
The Company recorded a tax provision of $25 million, an effective income tax rate of 10.7%, for the quarter ended June 30, 2009, and recorded a tax provision of $170 million, an effective income tax rate of 40.0%, for the quarter ended June 30, 2008.

Here are the elements we’re dealing with:

The effective tax rate element is a disclosure containing the above paragraph. Income tax expense is a number that will be footnoted using the same paragraph.

The disclosure paragraph will be text blocked. Effective income tax rate and income tax expense will be detail tagged.

Basic Guidelines
Here are some basic guidelines for detail tagging:
•    Only text-based paragraphs can be detail tagged.
•    Abstract elements may not be used as detail tags.
•    A detail tag applies to a data fact. Elements not having associated facts cannot be detail tagged.
•    In most cases, a detail tag applies to a numeric or date type element. A detail tag is a footnote to an existing data fact.

Detail Tag Granularity
An interesting point of discussion is how detail tags appear in instance documents. Of particular interest are detail tagging of disclosures that consist of multiple paragraphs.

Each paragraph may have its own set of detail tags. The question is how this is to be reported within the instance document. The lowest level of granularity provides maximum transparency. This means creating a footnote for each individual paragraph with links only to the detail tags pertaining to that paragraph only. The alternative is to have one footnote for the entire disclosure and then applying all detail tags that apply anywhere within the disclosure.

For example:

In the granular approach, two footnotes are created, one for each paragraph. The first applies to income tax expense/benefit and effective income tax rate only. The second applies to unrecognized tax benefits and the unrecognized tax benefits that would impact the effective tax rate.

Using the general approach, there is only one footnote. The entire disclosure is tagged to all elements applicable to any paragraph within the disclosure.

The granular approach provides more transparency to viewers, since detail tags are isolated to specific paragraphs. The entire disclosure including both paragraphs would be detail tagged to all four detail tag elements as a single footnote. Based on policies of the SEC of items two through four from the list at the beginning of this post, my interpretation is that a lower level of granularity is preferred. This is specifically stated in that each table within each disclosure is to be tagged as a separate block of text and that each numeric fact must be individually detail tagged.

Detail Tag Crawler
Detail tagging is a difficult process. It requires professional proficiency to achieve the quality of cross tagging required in the detail tagging process. There are over 16,000 elements in the US-GAAP. The question arises for each text-based data fact as to if and how to detail tag. A good software product will assist you in making smart choices. An intelligent detail tagging assistant compares your data fact to labels in the taxonomy in order to provide you with a selection of best choices. For each element it arrives at a matching weight of best possibilities to detail tag to. This is not an easy task and one that is not always conclusive. A crawler can match some tags, but not necessarily all that may apply. Let me again emphasize: Detail tagging requires human effort and prudence, regardless of the best of efforts achieved by your software.

Conclusion
The EDGAR Filer Manual (EFM) requirements are considerable. In my posts, I have only touched the surface of the many issues a filing process entails. The process of completing a filing requires two hats: (1) the reporting professional who makes decisions on mappings and when to extend or not to extend elements, and (2) a technician who understands these requirements and can translate them into an XBRL filing.

Regardless of the ease and simplicity of your XBRL software product, there is a learning curve that must be considered before moving filing services in house. Filing agents find this learning curve acceptable, since being able to convert filings to XBRL is a future necessity for filing agents to be able to stay in business. External reporting managers may consider outsourcing.