XBRL GL - Working Group Note - Amazing Account

Working Group Note dated 2007-07-08

XBRL-GL-WGN-Amazing_Account-2007-07-08.htm

is non-normative.

eric.e.cohen@us.pwc.com

PricewaterhouseCoopers LLP

Abstract

A discussion of the [account] structure in XBRL GL. XBRL’s Global Ledger Framework. “Accounts” have a much wider meaning in XBRL GL - because that is true in accounting systems globally. The [account] structure has many powerful tools, discussed here.

Status

Circulation of this Working Group Note is unrestricted. Recipients are invited to submit comments to the author or to the XBRL GL Working Group xbrlgl@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Table of Contents

XBRL GL - Working Group Note - Amazing Account 1

Working Group Note dated 2007-07-08. 1

1 Conventions. 2

2 Deliverables. 2

3 Why GL isn’t “General Ledger” and Accounts Aren’t What you Think. 2

4 What is an account? More than you might think. 3

5 XBRL GL and [account] - describing accounts and lines of detail 3

6 The [account] structure. 4

7 Let’s look at some data. 9

8 And some more data: a reporting tree. 10

9 Interrelationship between [account] and other structures. 11

10 XBRL GL representations: Where Accounts Are Needed. 12

11 Summary. 13

12 Additional Resources. 14

A. Intellectual Property Status (non-normative) 14

B. Document History (non-normative) 15

1 Conventions

· Elements from the XBRL Global Ledger Framework are indicated within straight brackets. For example, [entryDetail].

· Enumerated values from the XBRL Global Ledger Framework are indicated within curly brackets. For example, {voucher}.

· Elements from the XBRL Specification are indicated within angle brackets. For example, <schemaRef>.

2 Deliverables

After reading this document, you should be able to:

· Describe many uses of “accounts” in general ledger systems and sub-ledgers globally, including the use of the [account] structure in tax and other contexts.

· Identify important elements that are part of XBRL GL that drive the meaning of and interrelationships between accounts and help describe entries to accounts.

· Identify other structures in XBRL GL that overlap and complement the [account] structure.

Note

Throughout this document, I will cross-reference other documents that have been shared within the XBRL GL Working Group. For those of you who are employees of member organizations, you have access to these documents today. For those of you who are not members of XBRL directly or through one of its jurisdictions, some words of guidance:

· We, as working group, are working towards making other documents available to the public on an ongoing basis; if it isn’t available now, we hope it will be available soon.

· If you have need of the information in one of these documents, please inquire of xbrlgl@xbrl.org and let us know the circumstances; we can make the documents available on a limited basis to organizations in the process of implementing XBRL GL.

· We hope that you might consider joining XBRL and helping us in the XBRL GL WG to move forward together!

3 Why GL isn’t “General Ledger” and Accounts Aren’t What you Think

Moving information between operational, business and accounting systems, and sharing that information with auditors, tax preparers and regulators, is not a simple task today. Although the language of business is spoken by different software products, each uses its own vocabulary and terms to express that common language. XBRL’s Global Ledger Framework (XBRL GL) has been designed as a key to bridging systems, globally, and at any level of detail, from transactional entry through to end reporting. A basic understanding of XBRL GL’s generic and holistic concepts and structures is important for determining whether and how best to use XBRL GL as a bridge between systems.

In this document, we concentrate on one of the most fundamental business concepts in business reporting and accounting - the “account”. The English word “account” can be associated with “customer’s accounts”, “general ledger accounts”, “bank accounts” and more. The “General Ledger” module of an accounting software product contains different types of detail, depending on your jurisdiction or industry. Just as the “GL” of XBRL GL is not limited to the General Ledger - any ledger or sub-ledger, anywhere in the world - the account of XBRL GL is not limited to what most people typically think of. Both are important for the business requirement of integrating the business and audit reporting supply chain, from first transaction through end reporting.

XBRL GL is useful for representing sub-ledgers, documents, transactions, setup files, indicators and mappings. To find out more about how the [account] structure of XBRL GL is used to facilitate this, read on ...

4 What is an account? More than you might think

“Can I see your accounts?” That phrase has different meanings to different English speakers. In the UK, you “file your accounts” with the Companies House. (Alternatively, you might “lodge” them, but that is the subject of a different rant.) In the US, it would probably refer to only the “Chart of Accounts”, without any monetary values assigned.

A major contributor to the confusion of what is contained in the general ledger is the concept of an “account”. Depending on where you are from, you may think of the account list in your general ledger system containing:

· Accounts for the trial balance, like “Cash”, “Retained Earnings” or “Depreciation Expense”

· Breakdowns of certain accounts to additional underlying detail

o Breakdown of the cash account to individual Bank accounts

o Breakdown of receivables to Customers

o Breakdown of payables to Vendors

o Breakdown of inventory to Inventory items

o Breakdown of fixed assets/”property, plant and equipment” to individual fixed assets

o Breakdown of job work in process to Jobs

· Accounts or classifications for statistical accounts

· Definitions of reporting segments, such as departments, divisions, projects and other sub-account information

· Or maybe something else!

Accounts in XBRL GL are all of these – and more.

5 XBRL GL and [account] - describing accounts and lines of detail

Remember that XBRL GL is an account-independent and reporting-independent tool that lets you use XBRL GL’s [account] structure to represent all of these and more. In addition to representing accounts in this larger sense and related attributes, the [account] structure is also used to provide attributes for [entryDetail] lines and the different information those lines can contain.

In “One Man’s entryDetail is Another Man’s entryHeader”^{^[1]}, we discuss the hierarchical structure of XBRL GL^{^[2]} and how different representations of information required a “quantum leap,” where information as it moved from detailed representations to summary changed state from being represented at the entryHeader and entryDetail levels to entryDetail alone.^{^[3]}

XBRL GL provides other tools for going from “more detailed” representations to representations with less detail that may not require any change of state at all. XBRL GL’s [account] structure provides tools to help in going from detail to summary, which are described below in more detail; they include the fields [mainAccountType], [parentAccountMainID], and the joined [parentSubaccountCode] and [parentSubaccountType].

6 The [account] structure

Let’s take a look at the [account] structure.

Table 1: the [account] structure

Level 1	Level 2	Level 3	Level 4
[account]	Which contains:
	[accountMainID]
	[accountMainDescription]
	[mainAccountType]
	[mainAccountTypeDescription]
	[parentAccountMainID]
	[accountPurposeCode]
	[accountPurposeDescription]
	[accountType]
	[accountTypeDescription]
	[entryAccountingMethod]
	[entryAccountingMethodDescription]
	[entryAccountingMethodPurpose]
	[entryAccountingMethodPurposeDescription]
	[accountActive]
	And 0 to many	Which contains ▼
	[accountSub] ►	[accountSubDescription]
		[accountSubID]
		[accountSubType]
		And 0 to many	Which contains ▼
		[segmentParentTuple] ►	[parentSubaccountCode]
			[parentSubaccountType]
			[reportingTreeIdentifier]
			[parentSubaccountProportion]

· Level 1: the [account] structure

Modelled in Table 1, the [account] structure in XBRL GL is used to represent many things:

· The pure “account” from a general ledger;

· Sophisticated account structures with multiple dimensions;

· Customers and vendors;

· Banks;

· Jobs for job costing;

· Statistical accounts;

· Kits/bills of material for inventory;

· Multiple [account] structures associated by a single [entryDetail] parent can represent mappings between different accounts;

· [account] structures associated with other information within an [entryDetail] parent can represent mappings and provide unambiguous links for summarization purposes.

Some of the most important guidance related to what is being described comes from the annotated [accountType], with enumerated values of {account}, {bank}, {employee}, {customer}, {job}, {vendor}, {measurable}, {statistical}, and {other}.

Additional guidance comes from the [entriesType] (from the [documentInfo] section), which says whether the broader batch of information is an {account} listing, {entries} or some other kind of information.

The [account] structure lives at the level of [entryDetail] (a child of [entryHeader]), and you can have 0 to an infinite number of account structures. A single entryDetail may represent a chart of accounts listing, with as many [account] structures as needed to represent the company’s accounts. A single [entryDetail] may also have one [account] structure representing the account used for US GAAP, and another [account] structure representing a different account used for the same entry for IFRS, tax or management reporting (as driven by the guidance of the enumerated [accountPurposeCode] ).

· Level 2: Children of [account]

Some comments on the level 2 items:

Table 2: Children of [account]

[accountMainID]	This is the primary account number or code.
[accountMainDescription]	This is a text field that provides a more user friendly version explanation of what the account is or represents.
[mainAccountType]	A categorization tool largely used in absence of an XBRL financial reporting taxonomy link (through [xbrlInfo]), this is an enumerated field with values {asset} {liability} {equity} {income} {gain} {expense} {loss} {contr-to-equity} {distr-from-equity} {comprehensive-income} {other}. These enumerations come from FASB Concepts Statement No. 6.
[mainAccountTypeDescription]	Different accounting products have their own lists of account classifications. The free-form description field can be used in conjunction with or instead of [mainAccountType].
[parentAccountMainID]	Do you want to associate customers with the accounts receivable account? Or detailed inventory accounts with an overall inventory account? Perhaps your trial balance has summary entries like “current assets” that don’t have their own content but rely on the accounts underneath. Here is the tool for you; it lets you associate the current account with a parent account by including the parent account’s [accountMainID] here.
[accountPurposeCode]	An enumerated fields with values {consolidating}, {european} (in reality, this has the meaning of “jurisdictional” or “local”), {ifrs}, {offsetting} (developed for the need expressed by Japan for what I call “quadruple entry” bookkeeping), {primary}, {tax}, {usgaap}, {Japanese}, and {other}. Don’t worry about the words used in these enumerations - they are just codes representing the underlying need. This field is used both for an attribute to describe an account (when it is an entries list) and to describe the set of books the account is affecting (when it is part of a listing of entries).
[accountPurposeDescription]	This is a text field that provides a more user friendly version explanation of what the set of books is or represents. See the separate paper, “Maintaining Multi-GAAP Reporting with XBRL GL”^{^[4]} for more information.
[accountType]	Our core enumerated tool, with values {account}, {bank}, {employee}, {customer}, {job}, {vendor}, {measurable}, {statistical}, {other}
[accountTypeDescription]	A free-form field to be used in conjunction with, or instead of, the enumerated field [accountType]. Because of the importance of [accountType], we strongly recommend using it with [accountType].
[entryAccountingMethod]	An enumerated field to help describe the method of accounting used for an entry: {accrual}, {cash}, {modified cash}, {modified accrual}, {encumbrance}, {special methods}, {hybrid methods}, {other methods}. See the separate paper, “Maintaining Multi-GAAP Reporting with XBRL GL” for more information.
[entryAccountingMethodDescription]	A free-form field to provide the nuances of or alternatives to the enumerated [entryAccountingMethod].
[entryAccountingMethodPurpose]	An enumerated field to help describe the set of books that an entry (or this account structure within an entry) is associated with. Enumerated values include {book}, {tax}, {management}, {statutory}, and {other}. It can be further specified using [accountPurposeDescription] to state which set of book, tax or other type of reporting is being represented. See the separate paper, “Maintaining Multi-GAAP Reporting with XBRL GL” for more information.
[entryAccountingMethodPurposeDescription]	A free-form field to accompany or act as an alternative to the above.
[accountActive]	All “master file” structures in XBRL GL have an “active” flag. Many systems provide this to show that a master file that is “inactive” shouldn’t be used on new transactions; reports may also have an option to not show inactive items on the report.

This level also includes the ability to represent one or more sub-account structures [accountSub]; the content will be found in our next level.

The [parentMainID] is a powerful tool – one that can be used, as noted, for relating “child” customers to “parent” customers, “child” inventory to “parent” inventory, “child” jobs to “parent” jobs for representing buying groups, bills of materials/kits and master jobs and their spawn, respectively. Other uses are limited only by your imagination.

The use of the account structure to represent generic “accounts” can be seen in the sample instance documents at the GaLaPaGoS annotated instances, such as the Journal Entries example found at http://gl.iphix.net/HTML_ID/JournalEntry_Annotated_Instance.htm .

· Level 3: [accountSub]

XBRL GL is unique (as far as we know) in being able to represent complex account structures with unlimited sub-accounts/accounting segments.

Table 3: [accountSub] level data


[accountSubID]	This is the account number or code for the sub-account/segment.
[accountSubDescription]	This is a text field that provides a more user friendly version explanation of what the sub-account or segment is or represents. It does not describe the meaning of the type of segment (see below) but text associated with the specific [accountSubID].
[accountSubType]	This is where the meaning of the segment is placed. It is currently free-form, but suggested values are included in the documentation. These include “division”, “project”, “branch”, “profit center/centre”, “department”, “business unit”, “program”, and “fund”. As the [accountSub] is the primary tool for representing “dimensions” in an account structure, this could also represent product categories, customer types and regions.

A list of [accountSub] – without [mainAccountID] but with [accountType] – can associate dimensions with their source underlying data, such as customers or inventory items. An example of the use of the [accountSub] structure for this purpose – representing specifically “jobs” in job costing - can be seen in the annotated instance document “Job Master File” found in the annotated instances at http://gl.iphix.net/HTML_ID/Job-budget-v-actual.htm .

This level also includes the ability to provide additional attributes to the sub-account/segment described in this instance of the structure with the [segmentParentTuple] structure.

· Level 4: [segmentParentTuple] structure

This structure was developed to assist in the roll-up/summarization process. Some might compare the [accountSub]-[segmentParentTuple] relationship to the Dimensional taxonomy effort. It lets the user communicate how segments roll up to other segments and in what proportions.

The roll up may be to a summary item in the same [accountSubType]; for example, regions 101 - 199 roll up to region 100. Then you only have to state the [parentSubaccountCode] of the aggregate item. If you cross segments ([accountSubType]s), you need an additional piece of information; for example, if funds roll up to programs, then you need to state both the [parentSubacountType] and the [parentSubaccountCode] for the aggregate item.

Table 4: [segmentParentTuple] data

[parentSubaccountCode]	Identifies the [parentSubaccountCode] that the amounts in the current [accountSubID] will roll up to.
[parentSubaccountType]	Should the roll up be across types of segments, this is the [accountSubType] to which the [accountSubType] of the current subaccount will be summarized.
[reportingTreeIdentifier]	For organizations that wish to maintain more than one representation of roll ups - each of which can be called a “reporting tree” - this provides a place for the identifier of the reporting tree in which this particular roll up takes place.
[parentSubaccountProportion]	Where an allocation of the value associated with the current segment is to be made to more than one parent, multiple [segmentParentTuple] children for the same [accountSub] structures will allow a proportional allocation to more than one parent segment.

Anyone familiar with reporting tools such as FRx^{^[5]} is familiar with the need for information such as that XBRL GL seeks to represent here. An organization may wish to analyze its information summarized in different ways; one manager may wish to see manager results rolled up by regional managers and then by countries; another may wish to see cross-regional results by product line. The ability to store multiple reporting trees and associate sub-accounts and segments with parents differently for the reporting trees – and even do an allocation to different parent segments – allows XBRL GL to represent this important information to move from one business reporter to another.

We will discuss this more in the upcoming section “And some more data: a reporting tree”.

7 Let’s look at some data

As an example of the [account] structure representing an account, let’s use our traditional example of an account that might be used by a typical Rochester, NY, USA-based company to report their utilities. (We get some major heating bills here, so it will be a material amount.)

Table 5: Example of an account with four sub-accounts

In tabular form, this might be represented as in Table 6.

Table 6: Account represented in tabular form

Primary account	Reporting structure
5300	302	000	107	G
Utilities	Northeast	General	Sales	Government
Primary a/c	Division	Profit Center	Department	Project

Let’s assign it to XBRL GL elements, as in Table 7. Being a US-based company, we will use {usgaap} as the choice from the enumerated values for [accountPurposeCode]. We will also explicitly state that we are using this [account] structure to represent the commonly agreed upon {account}, as opposed to one of the other enumerations provided by [accountType]. Finally, as described in the commentary for the fields, we will use “expense”, according to those widely paralleled financial reporting FASB Concepts 6.

Table 7: Account associated with XBRL GL

Level 2	Level 3	Primary a/c	1^st segment	2^nd segment	3^rd segment	4^th segment

accountMainID		5300
accountMainDescription		Utilities
mainAccountType		expense
accountPurposeCode		usgaap
accountPurposeDescription
accountType		account
accountSub
	accountSubID		302	000	107	G
	accountSubDescription		Northeast	General	Sales	Government
	accountSubType		Division	Profit Center	Department	Project

8 And some more data: a reporting tree

XYZ company has business in the US, Canada and Mexico. In the US, we track information by region – Northeast, Northwest, Southeast and Southwest. Bill LePage oversees the North; Mary O’Donnelly oversees the South. Mary reports through another Mary, Mary Epp, who also has Mexico reporting to her; Mary Epp and Bill LePage answer to Lynn Jones, who also oversees Canada. Combined US results will be reported differently than results to either Mary Epp or Lynn Jones.

Looking at the Southeast; results roll to Mary O’Donnelly in one reporting tree, but to the United States region in another reporting tree. Assuming that Mary O’Donnelly is defined with Code MOD and Description Mary O’Donnelly as a Manager sub-account type, and the United States is likewise defined with code US and Description USA as a Country sub-account type, the relation of the Southeast region to those segments might look conceptually like this:

Subaccount	Content	Hierarchy instructions	Content
[accountSubDescription]	Southeast
[accountSubID]	SE
[accountSubType]	Region
And 0 to many		Which contains ▼
[segmentParentTuple] (1)►		[parentSubaccountCode]	MOD
		[parentSubaccountType]	Manager
		[reportingTreeIdentifier]	MGR-TREE
		[parentSubaccountProportion]	1.00

[segmentParentTuple] (2)►		[parentSubaccountCode]	US
		[parentSubaccountType]	Country
		[reportingTreeIdentifier]	CNTRY-TREE
		[parentSubaccountProportion]	1.00

9 Interrelationship between [account] and other structures

Some of the concepts that are represented by the account concept in some countries are represented by other groupings of concepts elsewhere. Let’s re-examine our list of things that are called “accounts” in different systems.

Accounts for the trial balance

Indisputable “accounts” in our experience; no parallel presentation.

Breakdown of the cash account to individual Bank accounts

We have discussed more cash management tools, but this remains the primary place for this. General ledger accounts (with [accountType] of {account} can be associated with a specific bank (an account with [accountType] of {bank}, as one example.

Breakdown of receivables to Customers

Customer information in more detail is provided in [identifierReference] using the enumerated field [identifierType], using the value {customer}. The [identifierReference] provides a primary ID, an unlimited number of tax/external IDs, contact information, address information and additional categorization tools. A customer, represented by an [identifierReference] structure can be associated with an accounts receivable account (an [account] with an [accountType] of {account} and a [mainAccountType] of {asset}) would associate the customer with a receivables account, while an [account] with an [accountType] of {account} and a [mainAccountType] of {income} could associate the customer with a sales account, for example.

Breakdown of payables to Vendors

Vendor information that mirrors the customer detail is provided in [identifierReference] using the enumerated field [identifierType], using the value {vendor}. As for customers, the [identifierReference] provides a primary ID, an unlimited number of tax/external IDs, contact information, address information and additional categorization tools. A vendor, represented by an [identifierReference] structure can be associated with an accounts payable account (an [account] with an [accountType] of {account} and a [mainAccountType] of {liability}) would associate the vendor with a payable account, while an [account] with an [accountType] of {account} and a [mainAccountType] of {expense} could associate the vendor with a default expense account, for example.

This same tool - [identifierReference] - is also used to represent (as the other enumerations in [identifierType] note) an {employee}, a {contractor}, a {salesperson-internal}, a {salesperson-external}, or an {other} party that is internally agreed upon.

Breakdown of inventory to Inventory items

Inventory and other items assigned to codes and categories are represented by the [measurable] structure. As described above, inventory items (and any other measurable) can be associated with inventory accounts, sales accounts and cost of goods sold accounts through mapping accounts and measurable items.

Breakdown of fixed assets/”property, plant and equipment” to individual fixed assets

Like inventory, fixed assets can be represented by the [measurable] structure. An example of the use of measurables and discussion of the use of account can be found in the annotated instance document found at http://gl.iphix.net/HTML_ID/BP_FixedAssetList.htm .

Breakdown of job work in process to Jobs

Jobs can be represented by the [jobInfo] structure. There is a detailed commentary on the advantages and disadvantages between representing jobs as accounts, subaccounts and with the [jobInfo] structure in the sample file found in our GaLaPaGoS tool (the tool is found at http://gl.iphix.net ). The current link to that instance is http://gl.iphix.net/HTML_ID/Job-budget-v-actual.htm .

Accounts or classifications for statistical accounts

Statistical account information may be represented in the [measurable] structure.

Definitions of reporting segments

Reporting segments can mean many different things. While primarily represented in the [account] structure, it may also be part of the classification of [identifierCategory] and [measurableCategory], or the [jobInfo] as above, or other detailed sources. The use of the [account] structure to represent a cost center as part of a payroll entry, for example, is described in the instance document at GaLaPaGoS at http://gl.iphix.net/HTML_ID/Employee_Timesheets.htm .

Use of [account] to Represent Tax and other Measures

XBRL GL was designed with the needs of businesses, tax preparers and tax administrations. Special accounts can be created that are tax-only or tax-specific. Tax tables and tax types can be mapped to liability and expense accounts. The accountPurposeCode is designed to indicate that accounts are tax-specific.

10 XBRL GL representations: Where Accounts Are Needed

XBRL GL can represent many types of files and information. Many of them involve accounts as an important part of the instance; some do not involve accounts, per se.

Examples of representations requiring accounts include:

· A simple chart of accounts (mirroring a “Chart of Accounts” file in an accounting system)

· A mapping between accounts (mapping, for example, a US GAAP Chart of Accounts to an IFRS Chart of Accounts or a local Chart of Accounts with a Corporate/Consolidating/Standard Chart of Accounts)

· A mapping from a set of accounts to one or more corresponding XBRL taxonomy elements

· Journal entries with associated accounts (and links to reporting taxonomies)

· Detailed or summarized Trial Balance reports.

Examples of representations NOT requiring accounts (in the US model) include:

· Customer master, vendor master, employee master, inventory master, fixed asset list (although any of these can be associated with an account for primary sales or expense account).

· Open receivables, payables and inventory stock status lists

· Performance metrics reports

Where Accounts may be useful:

· As we have discussed, “accounts” overlap other representation tools in XBRL GL. The [account] structure doesn’t store detailed information like contacts or addresses; it does describe interrelationships and hierarchies

· Because the account structure can present a hierarchy, and associate the account [mainID] with identifiers (customers, vendors, employees), measurables (inventory, supplies, services), and jobs, accounts used with these other representational concepts allow for master customer account/individual account, kit/bill of material and job/sub-job definitions.

11 Summary

· The [account] structure is used to describe accounts, in the international sense, which as a superset of “accounts” as they are understood globally is probably representing a lot more things than you may have expected.

· The [account] structure has sophisticated tools for roll-up by account and segment.

· Some of the content of the [account] structure is primarily for describing the account itself; other content is used to help describe the set of books to which an entry is posted.

· Tax-only accounts are part of XBRL GL’s extensive tax representational capability.

· XBRL GL can be used to associate a chart of accounts with another chart of accounts, a chart of accounts with a reporting taxonomy, a vendor list with the default account for each vendor, and other uses.

12 Additional Resources

The reader is encouraged, as always, to contact the chair of the XBRL GL Working Group at

xbrlgl@xbrl.org

Members of XBRL International can post questions to the INT-GL mailing list by joining the Working Group.

Others can take part in the public XBRL GL mailing list - go to

http://groups.yahoo.com/group/xbrl-gl-public

to find out more.

The XBRL GL portion of the XBRL International web site begins at

http://www.xbrl.org/GLTaxonomy

Our annotated best practice instance documents, webcasts of the XBRL GL Working Group monthly outreach calls and other useful resources are found in our GaLaPaGoS tool at

http://gl.iphix.net

The documents “One Man’s entryDetail is Another Man’s entryHeader” and “ Maintaining Multi-GAAP Reporting with XBRL GL” mentioned here are currently only available to XBRL International members, but it is expected that they will soon be released to the general public as XBRL GL Working Group Notes, like this document.

A. Intellectual Property Status (non-normative)

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

This document and the information contained herein is provided on an “AS IS” basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

B. Document History (non-normative)

Date	Editor	Summary
2007-07-08	Eric E. Cohen		Original Document.
2007-07-23	Hugh Wallis		Editorial for Publication

[1] This is one of those documents we hope to soon make publicly available, currently available within the consortium only.

[2] Which we further formalized in "Cross-referencing from XBRL FR to XBRL GL"

^{^[3]} As an example, an invoice might be represented in detail with individual [entryDetail] lines representing its detail lines and an [entryHeader] holding those lines together as one invoice, but as part of a group of invoices, that single invoice might be represented only by one line of [entryDetail] with the source journal representing the [entryHeader].

[4] Another document we hope to soon make public, currently internally available.