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.
Hi Peter,
Thank you for such an interesting insight
The use of formula specification looks way beyond its anticipated abilities.
In the above example you gave, in order to automate the process of updating the figures in labels,
I have following questions:
1) How do we tackle the situation, where the period ends are different i.e. based on last fridays or some other weekday or a last business day?
2) Will SEC rendering handle it?
3) If you could given a more detailed explanation along with an example of how formulas work?
Hi Peter,
May I confirm that you are going to generate a string fact, which is the 'label' in your context?
Thanks and best regards
Malix
To address Punya's three questions.
1. Actual ending dates are not as important as logical reporting periods. For instance, the various beginning and ending dates for various 4th quarters might differ, but logically they are still all 4th quarter reporting periods.
2. SEC rendering will handle this, because the label in the extension is an actual string, not a formula. Label formulas are translated into real values when the extension is generated.
3. A label formula pulls values for specific elements in reporting periods based on their logical references, rather than actual references. A logical reference might refer to last year’s 4th quarter. It does not refer to a specific date, so the actual reporting period of the logical reference changes as time goes by. Last years 4th quarter for 2009 is 2008. Next year, it would be a year later.
Peter thank you for your response.
I had some problem in understanding, if you could throw more light on the above example. When we say "label in the extension is a actual "string" are you trying to say, that this values i.e. whole label will be tagged separately to a string tag?