Issued: March 30, 2012
Impact: All US GAAP

Issue

The XBRL Consortium has issued the Units Registry, the latest version of which is located at http://www.xbrl.org/utr/utr.xml. This link shows the registry in a formatted table. The objective of the registry is to ensure that consistent units are used when companies report facts that may be measured in different ways. It also allows automated processes that ensure that appropriate units are used. However, since the introduction of the units registry, we have received a number of questions and seen a number of disparate ways of using it. This guidance is intended to reduce this variability and clarify areas of confusion and help smooth the path where there are inconsistencies in the taxonomy.

The units registry is approved by the SEC and should be used by companies to define units consistently and minimize changes in later filings. In 2013, the SEC commenced rejecting filings in which extension units of measure were created that conflicted with a UM in the Units Registry.

What is in the Registry?

The registry is made up of the following components:

  • unitID
  • unitName
  • nsUnit
  • status
  • versionDate
  • itemType
  • itemTypeDate
  • nsItemtype
  • symbol
  • definition
  • baseStandard
  • conversionPresentation
  • conversionContent
  • numeratorItemType
  • nsNumeratorItemType
  • denominatorItemType
  • nsDenominatorItemType

Each of these fields is explained in the units registry specification. Some of this information is relevant to filers and some is relevant to consumers of the information. For example, the filer should be concerned about selecting the appropriate unitID where a consumer of the information may be interested in using the conversion content to normalize units of measure i.e., if a consumer wants to see gas reserves in British Thermal Units versus barrel of oil equivalents.

Using the Registry to Report a Fact

Every number reported in an XBRL instance must have a unit of measure associated with it. The unit that is used is partially determined by the data type of the item. When creating an extension it is important that an appropriate data type is defined for each extension element. The data type selected depends on what is being defined. For example, if reporting the physical area of something, then use the area item type. If reporting the energy of something, then use the energy item type. Note the difference between these data types. A good example is oil and gas reserve disclosures. A company may report the actual volume of reserves in thousands of barrels or thousands of barrels of oil equivalents. These are two different data types: one is a measure of volume and one is a measure of energy. The available data types are defined in the data type registry at http://www.xbrl.org/DTR. The units registry offers lots of choices, but filers should be sure they select the correct unit for the data type. The units registry lists the data type that should be used with each unit.

The Edgar Filer Manual, Vol. 2 at 6.5.35 states the following:

If element “UTR” in a standard namespace is declared in the DTS of an instance, then the value of each “unitRef‟ attribute on each fact of a type in that registry must refer to a unit declaration consistent with the data type of that fact, where consistency is defined by that registry.

In the Document Entity Information (DEI) taxonomy, there is an abstract element called UTR. If the DEI taxonomy is imported into an instance, then the units defined in the XBRL units registry will have to be used. If the filer uses an element that has a datatype that matches a datatype defined in the units registry, then the filer can only use a unit associated with that datatype. No custom units are allowed for those datatypes defined in the registry. The decimalItemType, however, is not listed as a datatype in the units registry; therefore, custom units can be defined for this datatype.

A filer could define Kilowatts in an instance as <measure>DuckAndCover:Kw</measure> as long as the prefix is defined as:

xmlns: DuckAndCover =”http://www.xbrl.org/2009/utr” in the instance document.

This is identical to the manner that monetary item types use the iso4217 namespace.

<measure> isocodes:USD </measure>

xmlns: isocodes=”http://www.xbrl.org/2003/iso4217”.

ISO codes are not defined in the UTR namespace, but they are listed in the UTR registry which means a filercan only use an ISO code defined in the units registry if the UTR element is in the DEI.

To define a unit in an instance document, the unit would be defined as follows if using the registry:

xmlns:utr=”http://www.xbrl.org/2009/utr”<unit id=”ft3″>
<measure>utr:ft3</measure>
</unit>

Recommendation

Creating an Extension Unit

An extension unit should only be created when the unit required is not already defined in the registry.

Creating an extension unit is easy. It does not require defining any information in the company extension files. A peck (a measure of volume) is defined in the instant document as follows:

xmlns:abc=”http://www.abc.com/20110930″
<unit id=”anyUniqueIDYouLike”>
<measure>abc:peck</measure>
</unit>
Mismatched Data Types in the Taxonomy

In a number of cases, the data type in some versions of the US GAAP taxonomy does not match the actual item being described. In these cases, the filer would need to define their own unit. The filer should not use the pure unit in this case as a consumer of the data could not determine the unit used to measure the duration of time, i.e., a value of 23 is ambiguous as it is impossible to determine if this represents 23 years, 23 months, or 23 days. When defining a unit for duration items that are defined as decimal types instead of duration Item type, the filer should use the units for time defined in the unit registry. However, the namespace should be the namespace of the company. The values used should be Y (Year), M (Month), D (Day), H (Hours), MM (Minutes) and S (Seconds).

xmlns:abc=”http://www.abc.com/20110930″
<unit id=”anyUniqueIDYouLike”>
<measure>abc:Y</measure>
</unit>

Most of the duration type elements defined as decimals in prior taxonomies have been corrected. This rule is independent of defining units in the preferred label for elements.

Restrictions on the Use of the Pure Unit

The pure unit should only be used for ratios, rates, and percentages. The SEC guidance does not specifically state that numbers that are constants or multipliers can use the pure unit. However, given that these are effectively a reciprocal of a percentage, these too should use the pure unit.

The pure unit should not be used where the data type implies a unit of measure, such as area item type, volume item type, or monetary item type.

There are a number of items in the taxonomy that are not ratios, rates or percentages and are not included in the unit registry. These are usually counts of identifiable things. A number of these are prefixed by the word number. For example:

  1. Number of Stores
  2. Number of Employees
  3. Number of Restaurants
  4. Number of countries in which Entity operates
  5. Number of States in which Entity Operates
  6. Number of Contracts

In these cases, the pure unit should NOT be used as they are not a rate, percentage or ratio. The filer should define the following units:

Item Measured Unit
Number of Stores Store
Number of Employees Employee
Number of Restaurants Restaurant
Number of countries in which Entity operates Country
Number of States in which Entity Operates State
Number of Contracts Contract

The number of units that could be used for decimal or integer item types is very large (currently approximately 1,600 have been defined). Filers, however, should not use the units as a means to define what a concept is. In those cases where the concept defines what the unit is, the filer should use the unit defined in the concept. For example:

Element Define as a single unit Don’t use this
Number of Employees Employee Head Office Employee, person
Number of Stores Store Building, floor, kiosks
Number of Countries Country CountryAndTerritory

In order to disaggregate an element by geography, segment or other classifications, a dimension should be used; units should not be used to disaggregate a concept. The unit should not be used to disaggregate the element into components that represent a more specific breakdown of an element. For example, do not create different units for employees in different regions, such as US Employee, UK Employee, when tagging employees using the Number of Employees element. To capture this information, the geography axis should be used in combination with the country members US and UK.

If creating an extension element that is a decimal or integer item type, the unit used should be used in the description of the item to be consistent with those items in the taxonomy.

Units are periodically added to the units registry. The filer should check the units registry and use units defined before creating an extension to avoid rejection of the filing by the SEC.

Where the unit is defined as a component of the element, then a generic unit could be used to describe any unit. In these cases, use the unit “item” which can be used to represent any unit. This generic unit would be used when the filer has used pure in the past for disclosures that are not percentages, rates or a ratio.

Units, Scale and Decimals

The unit registry contains base units and units that have a scale. For example, the registry includes both barrels of oil, thousands of barrels of oil and millions of barrels of oil. These are all measures of volume that are scaled up by a scale of 1,000.

When a scaled unit is used, however, the decimal value will change depending what unit is used. If a filer reports 6,000,000 barrels the unit would be barrels (bbl) and the decimals would probably be -6. If the unit used is thousands of barrels (MBbls), then the value would be 6,000 with a decimals value of -3. If the unit is millions of barrels (MMBbls), then the fact would be 6 with a decimal value of 0.

Items in the unit registry may have a different scale than what the company typically reports. This does not mean that the defined unit cannot be used. For example, if inventory is weighed in 1000’s of tons, it does not mean a filer has to create a unit called “thousands of tons.” In this case, the ton unit should be used and the number reported should be multiplied by 1,000. The SEC also requires that if one item is reported with a particular scale, all items with the same unit should be reported using the same scale. 6.6.35 of the SEC Filer Manual states that each unit should only have one scale factor per instance. Therefore, use consistent units throughout the filing for measuring items with the same data type.

Using the Duration Units in the Units Registry?

The registry contains a number of duration units. These should not be used as a standalone unit. They are included in the registry to be used as a denominator of other units when other units are measured over a period of time. For example, gallons of oil a minute would be defined as (gallons/per minute) which is expressed in the XBRL exhibit as follows:

<xbrli:unit id=”gallonsPerMin”>
<xbrli:divide>
<xbrli:unitNumerator>
<xbrli:measure>utr:gal</xbrli:measure>
</xbrli:unitNumerator>
<xbrli:unitDenominator>
<xbrli:measure>utr:MM</xbrli:measure>
</xbrli:unitDenominator>
</xbrli:divide>
</xbrli:unit>

The items Y, M, D, H, MM, and S have no data type defined against them in the unit registry for this very reason.

In those cases where a company needs to report periods that are not durations, then they should use the duration units defined in the registry in their own namespace. For example:

The closing stock price must be above $15 for at least 10 days within a consecutive 30 day period for the bonds to become convertible.

To express the minimum 10 day period, the value P10D would not be suitable because it is not a ten day period, but rather a collection of 10 discrete days.

Using Units with the perUnitItemType

The US GAAP taxonomy includes a number of perUnitItemType data types for elements that typically express the price of something. When defining a unit for these items, the numerator must always be a currency such as USD and the denominator should use a unit from the unit registry or a custom unit if the unit is not defined in the registry. For example, the element AverageProductionCostsPerBarrelOfOilEquivalentsBOE should be represented as follows:

<xbrli:unit id=”ProdCostPerBOE”>
<xbrli:divide>
<xbrli:unitNumerator>
<xbrli:measure>utr:USD</xbrli:measure>
</xbrli:unitNumerator>
<xbrli:unitDenominator>
<xbrli:measure>utr:Boe</xbrli:measure>
</xbrli:unitDenominator>
</xbrli:divide>
</xbrli:unit>

When creating an extension item for something that represents a price of an item, then the perUnitItemType should be used.