Peter Boritz is the architect and chief technical officer for Snappy Reports XBRL.
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 ntains a label which provides human readability for spoken languages. There can be only one label for any given language and label category mbination. A problem ours if the label changes from filing to filing…For example, the label “Property Plant and Equipment of Aumulated Depreciation” is a static label. Typically, however, a label may more likely resemble “Property Plant and Equipment of Aumulated 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 sts 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 ntrol 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 nstant 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 “ of aumulated 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 mplete 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 ntrol purposes.
Formulas
The best choice is to use the same extension without the use of footnotes to aent labels. This can be done with variables.
A variable in a filing pulls the instance value for a specific element and ntext mbination. 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 mpensation of
{ GetValue(us-gaap:StockBasedpensation,CurrentDuration<12>):$#,###,##0 } and
{ GetValue(us-gaap:StockBasedpensation,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 – months)
For example, we are taking the current 12-month duration (current year) and mparing 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 mpensation for the current period and placing its value in the label labor expense. For the send portion, we are asking for the equivalent value for the previous year; it uld 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 de to format the value with a preceding dollar sign, thousands mma 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 mpensation 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 ntext — for instance, st 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 acrding to the localization set in the mputer. 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 uld 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 mplete and reliable for all detail tagging within the filing. The detail tag would be the element referenced in the formula. |