Using XBRL for Compliance Reporting can be sometimes tricky. Some of the simplest things can often be very hard to work out. This post discusses the use of ‘Period Type’ in XBRL reporting.
‘Period Type’ is the introduction of the concept
The concept of Period Type in XBRL seemed to be a clear-cut distinction between the American concepts of stock or flow. Things were either reported:
-
- as at a point in time – stock items, such as those you find on a balance sheet that is given the period type of instant in XBRL; or
- they were reported in respect of a period of time flow items, such as those you find on a P&L that are given the period type of duration in XBRL.
All pretty simple, right? And so it is for most things. But occasionally you can get into trouble if you are not thinking and it is remarkable how many times this simple decision is made incorrectly.
Usage of ‘Period Type’ for Numerical Data
With numerical data, there is rarely a problem if the value represents a balance as at a point in time then it is clearly an instant. If it is the aggregation of several values between 2 points in time then it is duration.
Some might argue int the balance is simply the aggregation of values up to that point in time, so how do you distinguish them?. The answer to that lies in a subtle difference. The balance is only the same as the aggregation in one special circumstance where the period of the aggregation is from inception otherwise it is the sum of the previous balance plus the aggregation of values. In the special circumstance, the difference is one of reporting intent the values are the same, but the intent of one is to show the result of the aggregation and the intent of the other is to show the aggregation itself.
Usage of ‘Period Type’ for Textual Data
Where people seem to come unstuck is with textual data, such as names and other contact details. The confusion seems to lie in the mistake of setting the period type based on what something is rather than the reporting intent. Many, many concepts can be reported both as at a point in time or over a period of time something our founding forefathers of XBRL did not really consider or perhaps did not fully grasp the impact of when they made the setting of period type mandatory as either instant or duration.
Let’s consider an organization’s name. Many taxonomies (including IFRS) set this concept with a period type of duration. This makes sense because it is effective for a period of time, however, if you think about the typical reporting intent of these items, it is to report the name as at the reporting date. Most of the time it makes no difference but if the entity in question has changed its name during the period then most financial statements and reports want the name as at the reporting date. If this is the requirement and the concept is instant then there is no problem and no confusion over how to report.
However, if this is the requirement but the concept is a duration we have some options to consider.
Handling ‘Period Type’: Suggested Approach
Firstly, do we extend the taxonomy to create a concept for the name with a period type of instant so that the semantics are all standard?
If not, what do we set the start date to be? The reporting process is simplest if all instant concepts are set with the reporting date and all duration concepts set with the start and end dates of the reporting period. If the entity’s name has changed mid-period then automatically set the start date this way results in incorrect information, so the process is complicated by having to check if the start date for the name is in fact correct.
Given that the taxonomy has a single concept for the name and this is identified via the semantics of period type as being the name during a period of time; and the entity has 2 (or more) such names for different periods within the reporting period; then it is not clear which of those names is the one expected to be reported. The taxonomy cannot, by itself, convey this information, so the process is compromised by either having to refer to something other than the taxonomy to determine the reporting requirement, or the user has to guess which value to report neither of which is a great use of XBRL.
Some have suggested that the answer is simply to set the start and end dates to the same value to emulate an instant concept. This works but is in my opinion clumsy and technically incorrect as the semantics of XBRL dictate that this means the date was effective for only that day, which is not true. People can infer what is meant by this, but computers cannot.
Always remember to think about the reporting intent when setting this and not be distracted by what the concept usually represents. For as long as the XBRL Specification makes this mandatory, we will have to take great care with this so as not to muddy the waters.
