In this discussion, we will consider the misconception that a dimension (i.e., [Axis]) can provide additional information. Refer to the US GAAP taxonomy - Dimensional Modeling 1.0 posting on October 21, 2014 for background information.
For purposes of this discussion, we will use ALAMO GROUP INC's ("ALG") Form 10-K as of and for the period ended December 31, 2013 that was filed on March 11, 2014 and Form 10-Q as of and for the period ended March 31, 2014 that was filed on May 8, 2014.
In the Dimensional Modeling 1.0 posting, the following fact was used as an example:
Form 10-K filed 2014-03-11
| ● | Value | 186,000,000 | |||
| Primary concept (i.e., Line Item): | |||||
| ● | Standard label | Business Combination, Consideration Transferred | |||
| ● | Element name | BusinessCombinationConsiderationTransferred1 | |||
| Contextual information: | |||||
| ● | Business Acquisition [Axis] | Super Products LLC, Wausau-Everest LP, and Howard P Fairfield LLC [Member] | |||
| ● | Subsequent Event Type [Axis] | Subsequent Event [Member] | |||
| ● | Period | 2014-02-23 to 2014-02-24 | |||
| ● | Unit of Measure | iso4217:USD | |||
| ● | Decimals | -6 | |||
| ● | Entity Identifer | 0000897077 | |||
In ALG's Form 10-Q filed 2014-05-08, this fact is current; it is no longer subsequent to the financial reporting period of the financial information included in the Instance document. The fact is as follows:
Form 10-Q filed 2014-05-08
| ● | Value | 186,000,000 | ||||||||
| Primary concept (i.e., Line Item): | ||||||||||
| ● | Standard label | Business Combination, Consideration Transferred | ||||||||
| ● | Element name | BusinessCombinationConsiderationTransferred1 | ||||||||
| Contextual information: | ||||||||||
| ● | Business Acquisition [Axis] | Super Products LLC, Wausau-Everest LP, and Howard P Fairfield LLC [Member] | ||||||||
| ● | Period | 2014-02-23 to 2014-02-24 | ||||||||
| ● | Unit of Measure | iso4217:USD | ||||||||
| ● | Decimals | -6 | ||||||||
| ● | Entity Identifer | 0000897077 | ||||||||
When XBRL data (i.e., facts) is reported over multiple periods, each fact from each reported Instance document imported into a database simultaneously exists. The search programming will generally provide an option to or the analytical programming will automatically select the most current fact reported (i.e., ultimus). However, this programming is only possible when the entirety of the contextual information is identical (i.e., value tagged with a primary concept defined by {[Axis]=[Member]; Period; Unit; Decimals; Entity Identifier}.
Note that the two facts in the example above do not have identical contextual information. These are two unique facts because the first fact that was reported in the Form 10-K includes the Subsequent Event Type [Axis]=Subsequent Event [Member] contextual information and the second fact reported in the Form 10-Q does not include the Subsequent Event Type [Axis]=Subsequent Event [Member].
Subsequent is not an aspect that characterizes a fact; subsequent is a characteristic of when the fact occurred relative to an earlier point in time. Time in XBRL is provided by the time [date] dimension, which is the period [date] context provided on each fact reported in an Instance document.
It is easily understood that "subsequent" is not a characteristic of a fact. Simply consider the entity's own accounting database. Each reporting [legal] entity (i.e., Legal Entity [Axis] contextual information) has its own General Ledger, each General Ledger is maintained on a single currency (i.e., Unit of Measurement contextual information), and each General Ledger is able to be opened or closed as of a given reporting period start and end date (i.e., period [date] contextual information), but no General Ledger has a "subsequent event" account or the equivalent transactional context because that is provided by the journal entry posting date (i.e., period [date] contextual information). If a financial reporting professional wants to know all events or transactions occurring after a reporting date, the professional queries the accounting database for all journal entries posted after a given date (e.g., period-end balance sheet date).
As promulgated by US GAAP (ASC Master Glossary), there are only two types of subsequent events: (1) recognized and (2) non-recognized. Recognized subsequent events occur because events or transactions occur after the balance sheet date and before the financial statements are issued or available to be issued that provide evidence of conditions that existed as of the balance sheet date. Non-recognized subsequent events are events or transactions that occur after the balance sheet date and before the financial statements are issued or available to be issued that do not provide evidence of conditions that existed at the balance sheet date.
Recognized subsequent events that are quantifiable are included in the financial statements of the period. As such, numerical facts tagged in XBRL format receive the Required Context (as defined by the EDGAR Filing Manual ("EFM") 6.5.19) or the end-date thereof and non-numerical facts; because they refer to an event or transaction that was recognized during the current period also receive the Required Context. As these facts receive the Required Context, the Subsequent Event Type [Axis]=Subsequent Event [Member] is not applicable.
Non-recognized subsequent events are the subject of the UGT structure shown below and which are addressed in the FASB UGT Implementation Guide, Version 2.0 June 2014 "Subsequent Events (UGT Version 2014)" ("Implementation" guide).
http://www.fasb.org/cs/ContentServer?c=Document_C&pagename=FASB%2FDocument_C%2FDocumentPage&cid=1176164156528. Non-recognized subsequent events receive a period [date] context that is after the balance sheet date. If one wants to know the subsequent facts relative to a single Instance document, query the database or data export for all facts that have a period [date] context after the most current balance sheet date. If one wants to know the subsequent facts across a population of companies, query the database or data export for all facts after the respective Document Period End Date fact value or the date of focus, if different.
It is inefficient and a poor use of XBRL to not use the time [date] dimension to identify subsequent event facts. Inefficient because the Subsequent Event Type [Axis]=Subsequent Event [Member] duplicates the time [date] dimension. A poor use of XBRL because the benefit of gathering subsequent event facts without using the period [date] context does not guarantee a complete population of data and forces programming to ignore the Subsequent Event Type [Axis]=Subsequent Event [Member] contextual information.
A fact is defined by the entirety of its context. Do not place a dimensional qualifier (i.e., Axis=Member) on a fact, if that dimensional context is not an aspect characterizing that fact (i.e., additional information). Suggesting additional information on a fact infers that the fact is not properly defined or that there is a second fact that should be reported, neither of which is applicable to a subsequent event.
| Consider the following: | |||||||||||||||
| Subsequent Event Type [Axis] | |||||||||||||||
| Subsequent Event Type [Domain] | |||||||||||||||
| Subsequent Event [Member] | |||||||||||||||
This is a structure provided in the UGT. The Subsequent Event [Member] is the only [Member] ever anticipated on the Subsequent Event Type [Axis].
The Subsequent Event Type [Axis]=Subsequent Event [Member] is placed on any fact that has period [date] context that is subsequent to the most current balance sheet date of a given Instance document (i.e., the period end date of the Required Context). In the Implementation guide, the contextual information of the Subsequent Event Type [Axis]=Subsequent Event [Member] is placed on every example subsequent event fact. In the Implementation guide, it is stated "Users may use “Subsequent Event Type [Axis]”, along with other elements in the UGT that describe their subsequent event. By using line item and dimension elements consistently, different events should have the same modeling structure whether they occur before or after the period being reported on."
"May use" is inaccurate since the expectation is that users "Will use" the Subsequent Event Type [Axis]=Subsequent Event [Member]. "…different events should have the same modeling structure…" is incorrect because events (i.e., facts) are established in the Instance document while the modeling structure is established in the extension taxonomy and different events (e.g., business combination, debt refinancing) have different extension taxonomy structures used to tag the related facts in an Instance document. The correct statement would be that a fact once reported should remain the same for all time (i.e., identical contextual information).
For example, as can be seen in the Form 10-K and the Form 10-Q facts above, use of the Subsequent Event Type [Axis]=Subsequent Event [Member] prevents the facts from having identical contextual information, since the prior fact reported (i.e., Form 10-K) has and the most current fact reported (i.e., Form 10-Q) does not have the Subsequent Event Type [Axis]=Subsequent Event [Member] dimensional context. The UGT model and related Implementation guidance prevents a subsequent fact once reported from having identical contextual information for all time.
The reason given for this UGT structure is that it provides additional contextual information on the fact, but as aforementioned, subsequent is not a characteristic of a fact, but of when that fact occurred relative to an earlier date. Providing period [date] contextual information on a fact is the purpose of the time [date] dimension. It is inappropriate to duplicate elements in an XBRL taxonomy, including primary concepts, dimension concepts, or abstract concepts. The Subsequent Event Type [Axis] is a duplication of the time [date] dimension, since it attempts to provide "timing of occurrence" contextual information on a fact relative to the reporting date of the Instance document (i.e., Required Context period end date).
The purpose of XBRL is not to provide an alternative to producing paper financial statements, but to allow consumers to create a continuous data set by directly importing the XBRL data. "Subsequent" is never an attribute of a fact, but the result of when a fact occurred and is communicated in reference to an earlier point in time. This is not necessarily intuitive for someone thinking of XBRL data within the construct of a single Instance document. However, expanding the understanding of XBRL data to a continuous data set highlights the issue of providing irrelevant context, such as the Subsequent Event Type [Axis]=Subsequent Event [Member] (see the two facts first shown above). Change is difficult and paradigm shifts are never easy. As such, Best Practice guidance has been issued supporting the aforementioned Subsequent Events Implementation guide's use of the Subsequent Event Type [Axis]=Subsequent Event [Member] on all subsequent facts in a given Instance document.
The Best Practice guidance is a compromise based on the Subsequent Event Type [Axis] only ever having a single allowed Subsequent Event [Member], which makes it possible to ignore programmatically (e.g., remove, strip-off) this axis-member combination on any fact consumed into any database.
As financial reporting professionals, we must first ask ourselves why it is necessary to provide context on a fact when such context is ignored for purposes of data consumption. Professionally, we base the commitment of resources on cost-benefit relationships and the cost of doing something that provides little to no benefit does not pass muster.
Obviously, the fact first stated above is subsequent to the year ended December 31, 2013 because the fact has a 2014-02-23 to 2014-02-24 period [date] context and it precedes any facts with a period [date] context that is after 2014-02-24. Likewise, it is abundantly apparent that the fact falls within the first calendar quarter because 2014-02-23 to 2014-02-24 is within the period from 2014-01-01 to 2014-03-31. The Subsequent Event Type [Axis]=Subsequent Event [Member] is unnecessary, does not change the fact, and provides no value.
Requiring tagging that is ignored on consumption is costly and inefficient.
The easiest way to mitigate this data issue is to correct the modeling of the UGT by deprecating the Subsequent Event Type [Axis]=Subsequent Event [Member]. However, to correct the model, the issue first must be acknowledged.