Are Your XBRL Business Reports XBRL Global Ledger SouRCeD?
A draft document to explain the SRCD module
Eric E. Cohen eric.e.cohen@us.pwc.com Version 70209
XBRL Global Ledger SRCD – for Unambiguous One-time and Automated Mapping from XBRL Global Ledger to XBRL FR (or any other XML Schema-based report)
See also prior documents:
- CrossRefFR_GL (December 2005)
- Unambiguous_GLtoFR (March 2006)
- Message 372 from INT-GL, dated 2006-09-20, titled “SRCD summary from Toronto F2F”
Introduction
XBRL’s Global Ledger is the bridge from business events and transactions to end reporting and, as such, is an extensible framework that can represent the drill-down detail that can support XBRL’s end reporting formats. The Global Ledger can represent all of the detail necessary for applications to summarize and aggregate the data in many different ways. In addition, the Global Ledger has, from its early days, included guidance of eventual summarization to end reports through the [xbrlInfo] structure.
Over time, two potential classes of users of the Global Ledger (in particular, as the detail for end reporting) have indicated they want other ways to drive the creation of end reports or to show the linkages to specific reports: both more sophisticated ways to drive XBRL FR[1] creation and “simpler” way of annotating the exact content in an original FR document that Global Ledger-represented facts relate to. The latter demand in particular has led to the development of the new SRCD module – Summary Reporting Contextual Data, new Global Ledger elements that help drive linkages to the “contextual data” (contexts, units and other attributes) found in “summary reporting” (especially XBRL FR reporting.)
The recent (February 2007) internal working draft of the SRCD module works with the existing XBRL Global Ledger Taxonomy Framework and is currently available in a palette that includes all of the current Proposed Recommendation modules. The elements of the SRCD, along with the existing [xbrlInfo] elements, are represented in Table 1: Content of [xbrlInfo] structure.
This
document assumes basic to intermediate knowledge of XBRL FR and GL instance
creation. Future versions will contain
actual XBRL GL textual examples.
Table 1: Content of [xbrlInfo] structure
|
Label |
Data expected |
|
XBRL Allocation |
Enumerated |
|
Summary Reporting Element |
QName |
|
Detail Matching Element |
QName |
|
|
|
|
Summary Tuple Path |
XPath |
|
Detailed Content Filter |
XPath |
|
Reporting Date Selector |
QName |
|
|
|
|
Summary Precision Decimals |
|
|
Summary Precision |
Non-negative integer |
|
Summary Precision INF |
None |
|
Summary Decimals |
Integer |
|
Summary Decimals INF |
None |
|
|
|
|
Summary Context |
|
|
Summary Entity |
|
|
Summary Entity Identifier |
Token |
|
Summary Entity Scheme |
URI |
|
Summary Entity Segment (See below) |
|
|
Summary Period |
|
|
Summary Period Instant |
Date |
|
Summary Period Start Date |
Date |
|
Summary Period End Date |
Date |
|
Summary Period Forever |
None |
|
Summary Entity Scenario (See below) |
|
|
|
|
|
These similar structures
are represented once here so the table will fit on a single page |
|
|
(1) Summary Segment and (2) Summary Scenario |
|
|
Summary Explicit Dimension |
|
|
Summary Dimension |
QName |
|
Summary Explicit
Dimension Value |
QName |
|
Summary Typed Dimension |
|
|
Summary Dimension |
QName |
|
Summary Typed
Dimension Value |
String |
|
Summary Simple Segment Content |
|
|
Summary Simple
Element URI |
URI |
|
Summary Simple
Element Name |
String |
|
Summary Non Dimensional Contents |
String |
|
|
|
|
Summary Unit |
|
|
Summary Unit Numerator |
Token |
|
Summary Unit Denominator |
Token |
All of these items are useful and important. Those with one of the following icons are specifically identified as either for more basic fixed connections between existing XBRL Global Ledger and XBRL FR instances (the “training wheel” icon) or more advanced for creating templates and automated function (the summation icon).
Key:
”Training
wheel” items
More sophisticated items
“Training wheel” items can in general be considered as hardcoded default values that, when present in a given [xbrlInfo] structure, override other means of extracting the same or similar information from other, more generic XBRL GL items.
Each of the items is explained below with narrative, description and examples of values. In future versions of this document, snippets of XBRL Global Ledger documents reflecting the content will be provided.
Xbrl Allocation
An enumerated field (gl-cor) that provides guidance to applications on whether the fact should be considered a beginning balance ({beginning-balance}), an ending balance ({ending-balance}) or a period change ({period-change}). This can drive some decisions for applications:
- Where the end reporting concept has separate labels for beginning and end of period, this can drive the selection of those labels.
- Applications working on “period change” situations will usually require appropriate cut-off dates for reporting and may need to reference other fields in XBRL Global Ledger to determine which transactions to include in which reporting periods.
- Matching to appropriate elements (instant, duration) can be tested or exceptions noted.
Example values:
- beginning-balance
- ending-balance
- period-change
Summary Reporting Element
A QNameItemType, this concept from (gl-cor) is the target element – the reporting concept in an XBRL FR taxonomy, or an element in a proprietary schema, that the detailed content in the XBRL Global Ledger instance is summarized to is described here. The associated namespace and the actual schema file would be noted in the open <xbrl> tag in the namespace declarations and would be discoverable by the application.
Example values:
- usfr-pte:Assets
- irs1120:OtherIncome
Detail Matching Element
A QnameItemType, this (gl-cor) is the concept in the XBRL GL instance that will be the focus of summarization. By default, the [amount] field is assumed to be the primary field that will be acted upon. However, there are many other fields, the most obvious of which are numeric, although the process is not limited to numeric content. The most likely alternative value would be the [quantity] field from the [measurable] structure.
Example values:
- gl-bus:quantity
- gl-muc:amountOriginalAmount
Summary
Tuple Path 
Sometimes identifying the target concept isn’t enough … such as when the target concept repeats over and over as part of a tuple. This concept allows an XPath expression to be provided in this stringItemType that describes exactly which occurrence of a tuple this content will go to/was represented by. The result of the XPath expression is a node.
Example values:
- To come – example of XPath expression for this purpose
- To come
Detailed
Content Filter
When establishing a template for automated mapping to end reporting concepts, sometimes it is necessary to define conditions for the mapping. This is especially important because XBRL Global Ledger uses generic structures for many types of structurally related, but semantically different, information. For example, you may only want to aggregate [amount], but if [amount] is not provided and [amountOriginalAmount] is provided, you would use that instead. Or you may only wish to provide [quantity] for certain types of measurables but not others. By providing an XPath expression in the stringItemType, you can communicate the standardized filter for the source information. The result of the XPath is a Boolean.
Example values:
a. To come – example of XPath expression for this purpose
b. To come
Reporting
Date Selector
XBRL Global Ledger provides many dates that can be associated with business events, transactions, and documents. While the default date would be the [postingDate], reflecting the accounting or reporting significance date, certain reports may be based on other dates. For example, an aged accounts receivable report would probably be based on the [maturityDate]. This tokenItemType value allows the explicit declaration of the date field in XBRL Global Ledger that should be looked to.
Note: More than one token at a time can be provided as content; this may allow a series of dates to be provided that can be assessed in order, in case a primary date has not been provided.
Examples values:
- gl-cor:maturityDate
- gl-cor:maturityDate gl-cor:postedDate gl-cor:postingDate
Summary Precision Decimals
Each numeric item in an instance document must have an attribute either describing the precision of the value or the trustworthy decimals. Although every numeric item in an XBRL Global Ledger instance would also have a precision or decimal, there is no science as to how to properly calculate the precision or decimal when many items are brought together. Applications may attempt to do so, or the value can be provided here.
One of the following four values must be provided:
Summary Precision
A non-negative integer.
Example values:
- 0
- 18
Summary Precision INF
Its existence implies that the precision value is INF
Example values:
a. No content is permitted. The existence of the concept itself conveys the meaning.
Summary Decimals
An integer.
Example values:
- 6
- -3
Summary Decimals INF
Its existence implies that the decimals value is INF
Example values:
a. No content is permitted. The existence of the concept itself conveys the meaning.
Summary
Context
Contexts in XBRL FR instances are where information about the organization whose business information is being reported (identifier) and possible sub-unit (segment), the time period associated with the facts, and any applicable scenario are provided. Segments can represent any logical and appropriate “slice” or “dimension” of the company. As noted above, in the discussion on the [reportingDateSelector], XBRL Global Ledger provides representations for many dates, any of which may be appropriate for an end report. And many of the typical “scenarios” found in end-reporting – e.g., budget, forecast, actual – are handled with specific XBRL Global Ledger enumerations and values.
Where the user wishes to explicitly hard code these values, rather than use programmatic means to determine them, the concepts found in this structure allow that definition.
Summary Entity
It is rare that a source system of detail contains an identifier that is used by a summarization system to identify it; the accounting system doesn’t usually hold the CIK code used to file an SEC filing. XBRL GL has fields to hold various external facing identification codes ([organizationIdenfier]/[organizationDescription]). Where this cannot be interrogated and used, the following fields allow the explicit description of the appropriate content.
Summary Entity Identifier
This token can be used to hold the value for the identifier.
Examples values:
a. XBRL GL Inc.
b. 529947
Summary Entity Scheme
This URIItemType can be used for the scheme.
Example values:
- http://www.sec.gov
- http://www.mycompany.com
Summary Entity Segment
The segment and the scenario of the context are very similar; both allow free-form content, both can be used in conjunction with Dimensional taxonomies. The explanation for the fields provided will be very similar. However the ties to XBRL GL are somewhat different.
Related to segments, XBRL Global Ledger represents the underlying detail from which certain aspects can be considered segments or dimensions. Companies for business intelligence uses can consider many different fields important for “slicing and dicing” data. Customer categories, inventory product classes, divisional breakdowns – all at different levels of aggregation – these are common dimensions used in reporting, but drawn from different database fields, all able to be represented with XBRL Global Ledger.
Where this information will be hard coded, this structure will be used.
Summary Explicit Dimension
“Explicit dimensional taxonomies are those in which the XBRL items form a discrete, countable finite partitioning of a set of members, which hereinafter is called a domain.”
Summary Dimension
A QNname
Example values:
- geo:Continent
- geo:SouthAmerica
Summary Explicit Dimension Value
A QNname
Example values:
- c:
- n:
Summary Typed Dimension
Typed dimensions occur “when the number of members is impractically large to enumerate explicitly.”
Summary Dimension
A QName
Example values:
- tax:dCustomer
- tax:dPhone
Summary Typed Dimension Value
A string
Example values:
- <cust>01742</cust>
- <phone><country>7</country><city>7</city><number>5555555</number></phone>
Summary Simple Segment Content
For very simple content – essentially an empty element that describes the segment - this structure allows a URI to describe the namespace and an element name
Summary Simple Element URI
A URI
Example values:
- http://www.globalledger.org
- http://www.bugmenot.com
Summary Simple Element Name
A string.
Example values:
- budget
- audited
Summary Non Dimensional Contents
When all else fails, this is a catch-all for any type of content. It is a string, and anything can be placed here – just no promise that it can be recognized and processed by the consuming application. However, that is the nature of allowing any freeform information to be placed in the segment or scenario.
Examples are:
- You can <whatDoYouKnow>place</whatDYouKnow> anything you want &in a segment or scenario!
- bananas
Summary Period
XBRL Global Ledger provides representational capabilities for the many dates associated with business transactions, events and documents. Where it is determined that hard coding a date is a more appropriate path, it can be done using this structure. Users can provide either the instant, the start and end date of the duration, or specify that forever is the appropriate period.
Summary Period Instant
If the value is an instance, it can be provided here.
Example values:
- 2006-12-31
- 2007-04-30
Summary Period Start Date
If the value is a duration, the starting date is coded here.
Example values:
- 2006-01-01
- 2007-04-01
Summary Period End Date
If the value is a duration, the ending date is coded here.
Example values:
- 2006-12-31
- 2007-04-30
Summary Period Forever
If the context should indicate this is a “forever”, this element is included. It takes no content.
Example values:
- None – this item takes no value; its presence indicates this is a forever situation.
Summary Entity Scenario
The most common and well-known examples of FR scenarios – actual, budget, projection/forecast – are explicitly handled with XBRL GL through other means (in particular the [entryType] and specific budget oriented fields.)
Where it makes more sense to hard code the scenario information, it can be done with this structure, which is virtually the same as the segment’s counterpart.
[EEC Note: as this duplicates the Segment above, wait for the information there to finalize, and then duplicate with more relevant examples here.]
Summary Explicit Dimension
Summary Dimension
Summary Explicit Dimension Value
Summary Typed Dimension
Summary Dimension
Summary Typed Dimension Value
Summary Simple Segment Content
Summary Simple Element
Summary Simple Element URI
Summary Simple Element Name
Summary Non Dimensional Contents
Summary
Unit
Units of measure can normally be found in XBRL Global Ledger by unit of measure concepts associated with monetary and quantity concept fields. For example, [amount] is associated with [amountCurrency] and [measurableQuantity] with [measurableQuantityUnitOfMeasure]. Where hard coding, rather than determining, the appropriate unit of measure is determined to be the best course of action, it can be provided with this structure. It will be up to implementation/applications to handle differences between the actual units and the summary units; no capture of conversion factors has been contemplated for this version of SRCD.
The unit of measure is most often a single value (ISO 4217 and a currency indicator for monetary items, custom for most other purposes), but sometimes can be fractional, with both a numerator and a denominator.
Summary Unit Numerator
A token value, which would include QName values.
Example values:
- ISO4217:usd
- my-ns:cs (cases)
Summary Unit Denominator
A token value; one may wish to assume that providing a
denominator only means the numerator is 1 by default.
Example values
- xbrli:shares
- my-ns:m2 (square meters)
Appendix 1: Issues and overlaps
[summaryReportingElement] holds the element in the end reporting taxonomy that the fact will be summarized to.
- The data type of the target element may be inconsistent with the data type of the original source element; the default source element is [amount], so a non-monetary target element is an issue.
- The period defined for the element may not coincide with the type of period described in the [xbrlInclude]
- The element may not be numeric, and should not have [summaryPrecisionDecimals]
- The element may be inconsistent with requiring a [summaryUnit]
[detailMatchingElement] is a pointer to an element other than the default [amount] field.
- The data type of the [summaryReportingElement] may be inconsistent with this element.
[xbrlInclude] notes whether the fact is a beginning balance, an ending balance or a period change. This can help drive the selection of an appropriate label role and guide in testing the selection of an appropriate [summaryReportingElement].
- The [summaryReportingElement], which in the taxonomy is an instant or a duration, may not match.
- The [summaryPeriod] may be set as an instant or a duration, and may not match.
[reportingDateSelector] identifies which of the many dates in XBRL Global Ledger should be used as the basis for summarization.
- There may be a conflict between an explicit reporting date given by [summaryPeriod] and the result from considering this field.
[summaryPeriod] permits the explicit statement of the date to be used in the context.
- There may be a conflict between this field and the data calculated using the [reportingDateSelector]
- The type of date (instant, duration) provided here may not agree with the type of period described in [xbrlInclude]
[summaryUnit] permits the expression of information that should be represent in a unit structure.
- The [summaryReportingElement] may have a datatype inconsistent with the use of a unit of measure.
[summaryPrecisionDecimals] allows the hard coding of the line item precision or decimal attributes.
- The [summaryReportingElement] may not be a numeric value, and should not have precision or decimals.
[summaryUnit] is a structure for providing the units of measure for the unit structure.
- How to ensure that the rest of the content matches up with the provided summary unit
o Making sure that monetary summary unit information based on ISO 4217 is provided for monetary values
o Making sure that the source and target information is appropriate for fractional information; using the denominator only where appropriate
o Future growth may include a conversion table between different units of measure.
Appendix 2: Philosophical Issues
In general, XBRL Global Ledger grows in ways consistent with the XBRL Global Ledger Philosophy. This series of statements is the pattern against which additional official modules are cut.
However, the XBRL Global Ledger Philosophy was somewhat set aside in the considerations of the SRCD. Other philosophical issues were put in place due to the needs expressed within the consortium to better hook together GL and FR. In particular, the need for “Training Wheels”[2], a very simple way to “hard code” the end reporting contexts, units of measure and other metadata in the XBRL Global Ledger instance. SRCD is primarily to link between existing XBRL Global Ledger and XBRL FR instances; it is not primarily intended as the perfect automation engine.
The SRCD module, therefore, has been developed to allow this representation but seek to be as simple as possible. This means that it may be perceived as somewhat limited. For more complex uses, the SRCD includes more advanced guidance for automated conversion and drill down, and we will continue to consider how to both provide additional fields and use XBRL Formula and other guidance.
Although SRCD currently has both more beginning and advanced tools, one thing it has not sought to emulate were “ids” used to associate concepts in FR documents with their related contexts or units. Likewise, we discussed the possibility of including SRCD elements at the [documentInfo] and [entryHeader] levels to allow inheritance, but have decided against it for the time being.
Appendix 3: Technical Notes
Tokens are text (string) fields with a few limitations; no line feeds, no carriage returns, no tabs, no leading or trailing spaces, no strings of more than one space at a time. See http://www.w3.org/TR/xmlschema-2/#token for more information.
It is our understanding that when populating an element with token as content, you can provide multiple values. This can allow a hierarchy of values – the first value with the greatest importance, the second value can be used if the first one “fails” or isn’t provided, and so on.