Written by Hyungwook Yoon, Hangjung Zo, and Andrew P. Ciganek     Posted on March 23, 2010

Hyungwook Yoon and Hangjung Zo are, respectively, a Doctoral Candidate and Assistant Professor at the Korea Advanced Institute of Science and Technology. Andrew Ciganek is an Assistant Professor at the University of Wisconsin-Whitewater.
        
With the increased use of XBRL, we are finding new opportunities to research this technology.  Based on the popular belief that XBRL adoption within the financial industry leads to reductions in the costs to both obtain and integrate what was once disparate financial data, we decided to examine whether such benefits were actually occurring.

We examined data from 550 companies in the Korean stock market. All publicly-held Korean firms have been required since October 2007 to electronically file their periodic and other financial reports in XBRL format through the DART (Data Analysis, Retrieval and Transfer) system, which is equivalent to the EDGAR system in the U.S.. Therefore, the Korean stock market presented an opportunity for us to examine the influence that XBRL adoption has for organizations.

The primary objective of our research was to determine whether XBRL adoption leads to a corresponding reduction in information asymmetry, where a select few investors have better access to information. We did this by investigating the bid-ask spread of those Korean companies, which is often used as a substitute for information asymmetry.  Monthly relative spread data was collected for seven years from September 2001 to August 2008, since this period was the most recent stable period in the Korean stock market. (The Korean market was extremely unstable for nearly four years before September 2001 because Korea experienced a severe economic crisis.  Korea officially escaped economic turmoil in August 2001.) The period after August 2008 was not included as a target period because the global financial crisis, caused by the collapse of major investment banks in the U.S., severely affected the Korean financial market.  

The result of a multiple regression analysis showed that XBRL adoption did reduce the information asymmetry of the Korean stock market, creating a more balanced system of transactions. In particular, this study confirmed that the effect of XBRL adoption on reducing information asymmetry is significant only for large companies. This relationship between firm size and information asymmetry was expected since previous research has shown that larger companies are likely to have more trading transactions, attention from analysts, and media coverage than smaller companies.  

XBRL adoption increases the transparency and quality of corporate information in the capital market and reduces the time and cost to circulate corporate information in stock markets, as well as enhances the compatibility of this information for integration among different information systems.  By facilitating corporate disclosure, information asymmetry of the capital market is notably reduced.

Our research paper with our methodology, findings, and conclusions can be purchased online.   

Written by Peter Bortiz    Posted on March 4, 2010

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

In one of my recent posts, I mentioned the problem of handling changes to labels between filings to the SEC. I noted that:

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…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.

An optimal reporting solution to this problem would minimize changes to the extension as much as possible; this would provide maximum reusability and minimizes labor costs and time. Three solutions present themselves: cloning, footnotes, and formulas.

Cloning
One solution is to clone a new extension for each filing and then change labels for each clone. Utilities may be used to clone one filing to another. This gets cumbersome, however, and it requires manual operations and extensive quality control review. This solution is not scalable and is the most primitive of the options presented.

Footnotes
Another option is to keep the label as a constant and use a footnote to denote the variable portion. This solution works nicely. The taxonomy label remains “Property Plant and Equipment” for all filings, but each filing would footnote the variable portion of the disclosure as “net of accumulated depreciation of $x and $y”.

The problem with this solution is that many viewers do not display footnotes – most notably, the SEC’s. Their viewer may be the yardstick with which your clients and peers are measuring the quality of your work. The reality is that your clients and peers need to see a complete rendering that includes everything. The use of footnotes to disclose the variable portion of labels works nicely, but it is missing a mechanism for quality control purposes.

Formulas
The best choice is to use the same extension without the use of footnotes to accent labels. This can be done with variables.

A variable in a filing pulls the instance value for a specific element and context combination. This is particularly handy with labels and disclosures. Variables are defined in the XBRL functions and formulas specification. However, the specification does not apply variables to labels. We can use a subset of functions and formulas for processing labels.

Our goal is to derive one or more instance values based on variables. For a specific element, we may want to obtain the current instance value for the current period or previous period. A previous period may be a year, semester, or quarter for an equivalent period in the previous year.

Our label problem with may be solved with pseudo syntax similar to:

Labor Expense including stock-based compensation of
{ GetValue(us-gaap:StockBasedCompensation,CurrentDuration<12>):$#,###,##0 } and
{ GetValue(us-gaap:StockBasedCompensation,CurrentDuration<12> - 12):$#,###,##0 }

The above is a fabricated syntax for display purposes only. We are telling an XBRL processor to make two substitutions in our label. Based on a given element, we are getting the data facts for a specific reporting period. The syntax is:

    GetValue(Element, Reporting Period<Length> - months)

For example, we are taking the current 12-month duration (current year) and comparing it to the equivalent reporting period in the previous year (Period – 12 months). If our current period is year ended 2009-12-31, then year minus 12 months would be 2008-12-31. The beauty of this is that our syntax is relative to our filing and it is totally reusable.

In the first instance, we are taking the value of stock-based compensation for the current period and placing its value in the label labor expense. For the second portion, we are asking for the equivalent value for the previous year; it could also be for the prior quarter, or an equivalent quarter in the previous year.

The “funny piece” I have included is $#,###,##0. We need a way to tell the processor how to format the number. In this example, I am using standard Microsoft formatting code to format the value with a preceding dollar sign, thousands comma separated, and no decimals.

The processor makes the required substitutions and places them into the label at run time. This means the same functionality always pulls applicable values based on your current filing period. Once you set the label, you never have to change it from filing to filing. This solves scalability issues and makes our life easier.

The instance or report would display the label similar to the following.

Labor Expense including stock-based compensation of $1,000 and $1,200.

Function is an important aspect to dynamic labels. We are not always looking for the value of the data fact. We may also be looking for a date value based on context -- for instance, cost of sales of $1,000 as of 12-31-2009.

A formula for obtaining a date may look something similar to the following.

{ GetDate(CurrentDuration<12>.– 12,End):MM-dd-yyyy }

GetDate returns a binary date/time. You can format it any way yhou want. The format yyyy would return the year only, as in 2010. European dates are dd-MM-yyyy. Another option is to use localization. This would set the date format according to the localization set in the computer. GetDate requires either an End or a Start parameter for duration periods. You need to know if we are requesting the date at the start or end of the period.

The use of formulas may also be handy in disclosures where the text block makes reference to the value of an element elsewhere in the taxonomy. For instance, if a numeric value within a disclosure refers to an element, a formula could be used for populating the numeric fact within the disclosure. This not only provides reusability and scalability within your filings over a span of time, but it also sets you up for detail tagging. The formula not only obtains a value, but it also identifies that the element from which the data is being pulled is a detail tag for that disclosure.

If force of habit requires you to always use formula based numeric facts within your text blocks rather than static text-based numbers, you would have fairly high assurance that your detail tagging is complete and reliable for all detail tagging within the filing. The detail tag would be the element referenced in the formula.