Chapter 10-understanding usfrtf

FINANCIAL REPORTING USING XBRL – IFRS AND US GAAP EDITION (2006-03-01)

© 2006 UBmatrix, Inc 203

10. Understanding the US Financial Reporting Taxonomy Framework

In this section8 we will explore the US Financial Reporting Taxonomy Framework (USFRTF) with a focus on explaining the fundamentals of the taxonomies. This will provide users with the knowledge they need in order to begin reading, comprehending, and using these taxonomies for financial reporting or analyzing financial information which make use of financial information expressed in XBRL.

While obtaining this understanding of the taxonomy is a process that will take some time and effort, this investment in truly understanding the taxonomy will be worth while. Not possessing a good understanding will make everything about using the taxonomy more challenging.

From a big picture perspective, the following captures information about what the USFRTF is and what it is not:

• The USFRTF is not intended to represent authoritative GAAP or SEC guidance, but rather a suggested model that can be used as a starting point for companies to use to create XBRL instance documents.

• The framework can be, and is intended to be, modified to express financial reporting information as desired by individual companies.

• Although the USFRTF is intended to be as comprehensive as possible, it should not be seen as a guide for what should or should not be included in the financial statements of a company.

• The USFRTF is not intended to redefine US GAAP, but rather to capture information about the application of these existing pronouncements as they in practice today.

• The framework models alternative presentations and calculations which can be used; however, it does not provide every disclosure option.

• The USFRTF does not infer that one presentation or calculation method is preferred over another, but it does model more commonly followed approaches.

• It is assumed that companies will create company extension taxonomies to express information which they wish to disclose, which is not contained in the USFRTF. In addition to defining new reporting concepts within company extension taxonomies, companies may also change relationships expressed within the framework.

• The USFRTF does not distinguish between concepts which need to be disclosed and those which do not need to be disclosed by a specific company. It simply provides concepts. Not all concepts are intended to be used by an company. Professional accounting and financial reporting knowledge and judgment are needed to properly apply the USFRTF to financial reporting information.

• The USFRTF does not distinguish between presentation (presented on the face of the face of the balance sheet, income statement or statement of cash flows) and disclosure (presented in the notes to the financial statements).

The inclusion of concepts within the USFRTF is based on their historical occurrence in financial statement disclosures.



10.1. Background to Set Perspective First we want to establish some grounding to get common misperceptions surrounding XBRL out of the way so they don’t interfere with truly understanding what the USFRTF really is.

The USFRTF has been in development for a number of years and is truly on the cutting edge of XBRL taxonomy development. The first US XBRL financial reporting taxonomy was created and released in July 2000 (based on XBRL 1.0). It was a significant effort to create the world’s first XBRL taxonomy and creating it contributed significantly to understanding what XBRL was, what XBRL needed to be and what tools were necessary. Unfortunately, this first XBRL taxonomy was not really usable for "production" financial reporting but instead served as an important learning experience for what was to come.

The current USFRTF is several orders of magnitude beyond the first XBRL US financial reporting taxonomy in terms of its functionality and purpose but the taxonomy is still really in its infancy.

When XBRL was first introduced, there was no "guidebook" for creating taxonomies, no examples to follow, etc. All this had to be developed by those blazing the trail. There is a bit of a trail now, as XBRL International has created and released the FRTA (Financial Reporting Taxonomy Architecture) and FRIS (Financial Reporting Instance Standards) guidance which provides best practice/guidelines on building taxonomies and instance documents, respectively. But, at this phase, there is still more that is unknown and to be discovered or figured out than there is know.

The USFRTF was created, or rather "evolved", over a number of years. It was physically created by a small group of people. This small core group collected, synthesized, and then incorporated feedback from many, many others who entered, but then exited this process of creating the taxonomy framework. Feedback has also been received from US GAAP technical specialists in "the Big 4" and regional accounting firms as well as other groups which are interested in seeing the USFRTF created.

The USFRTF expresses concepts presented or disclosed in financial statements, prepared using US GAAP for public profit-oriented companies. The precise accounting pronouncements covered and other information about the taxonomy will be discussed below.

But first, we want to set the proper perspective so you can truly understand the USFRTF.

10.2. An Accountant's Perspective: What is the USFRTF? If you were forced to describe the USFRTF in terms of something accountants are familiar with, that something would be a sample or "model” financial statement which contains all presentation and disclosure information of a company reporting to the US Security and Exchange Commission under US GAAP (SEC). It contains information which must be reported based on US GAAP, SEC regulations and common practice.

Another metaphor is using the popular AICPA guide, Accounting Trends and Techniques, which is an annual survey of accounting practices which are followed in 600 financial statements. The USFRTF condenses reporting down into one common option, but then is flexible and lets reporting entities modify the taxonomy to meet their individual needs.



The USFRTF (model) is "consensus based", meaning it is not issued by one of the Big 4 or regional accounting firms; instead, it is as if these firms banded together and merged their thinking into a single model. Where their internal models were different, they reached consensus on how the model should be combined to create the USFRTF (merged model).

This is an oversimplification to achieve a desired result, as the USFRTF is really not a model; instead, what we are trying to do is achieve a "grounding" and then move from that grounding to discussing the details of what the taxonomies actually are that make up the USFRTF. We want to dismiss misconceptions that people have.

The USFRTF has some characteristics of concepts organized to be used to create a model financial statement but it is not a model financial statement. But let's start there and build on this understanding.

In this section, we will explain the USFRTF from an accountant's perspective. We will try to avoid using XBRL terms as much as possible and stick with accounting terms. While we will need to use some XBRL terms to explain some essential aspects, we will try to keep them to a minimum.

If an accountant looks at the USFRTF, in particular the presentation linkbases, they should be rather familiar. It contains a large amount of accounting terms, things that accountants understand, and things which, believe it or not, technical IT people try and stay away from. (Go to most information technology type people and say "debit" or "credit" and watch their hair stand on end!) Familiar terms include things like "Balance Sheet", "Income Statement", "Cash Flow Statement", etc. In addition, the presentation linkbase is structured in a manner very familiar to accountants. “Income Statement” can be thought of (and in fact seen) as a hierarchy that contains “Revenue”, “Expense” and “Net Income” concepts in that specific order (i.e. the same way a company tends to present its Income Statement).

To help answer the question "What is the USFRTF?", first some details about how the USFRTF was created will be helpful. We then explain more clearly what the taxonomy framework is, once we have set the appropriate perspective.

10.2.1. Taxonomy Defined The USFRTF is a collection of taxonomies. But what is a taxonomy?

So, we start with the definition of the term "taxonomy". Taxonomy is not an accounting term, as you may have determined by now. But it is also not a "technical term". The term taxonomy is a term used in science and other domains and comes from ancient Greek word that means "structured dictionary”. A taxonomy can be thought of as a "system of classification relating to a topic" or as a "division into ordered groups or categories". For example, a taxonomy of soccer terms might include ball, goal, World Cup, etc.

The USFRTF expresses its system of classification relating to the topic of financial reporting under US GAAP and SEC regulations using XBRL, an XML-based language for representing business reporting information.

The USFRTF is a representation of financial information prepared in accordance with US GAAP. The taxonomy framework is a collection of concepts and relationships between those concepts. The taxonomy framework does not define the concepts; the FASB (Financial Accounting Standards Board) and other standards bodies define the concepts. The concepts in the taxonomy framework reference these standards within the taxonomy.



The connection between the USFRTF and US GAAP is limited to the taxonomy framework being based on the presentation and disclosure requirements of US GAAP and it does not add to, modify or even contribute to the standards in any way. It allows you to identify concepts in the financial statements prepared under US GAAP using consistent descriptions found in the taxonomy framework and the accounting standards.

10.2.2. Other Information Neither the Big 4/regional accounting firms, the FASB (Financial Accounting Standards Board), the PCAOB (Public Companies Accounting Oversight Board), nor the US Securities and Exchange Commission endorse the USFRTF taxonomy in any way. But, the Big 4/regional firms did help create it, as did the AICPA (American Institute of Certified Public Accountants).

The taxonomy is not static, it is dynamic. It can be changed, and is in fact designed to be changed. There are no limits XBRL provides on what can be moved around and what should not be moved around within the taxonomy by a company extension taxonomy.

Using the taxonomy will help the taxonomy evolve to its appropriate state.

10.2.3. Not a Model Financial Statement or Disclosure Checklist

The "backbone" of how the USFRTF was created, and also one benchmark for judging the USFRTF in terms of accuracy and coverage by accountants, has been the actual financial statements and disclosure checklists that are used by the Big 4 accounting firms in the preparation of financial statements. Initially, when work first began on the very first US GAAP taxonomy, accountants came with their US GAAP accounting technical experts, their sample financial statements, and their disclosure checklists. Very few (if any) of the accountants had even heard of XBRL. When reviewing the USFRTF, accountants commonly compare the USFRTF to their sample financial statements and disclosure checklists.

The sample financial statements and disclosure checklists are easier to read than reading through the standards and trying to create a financial statement. That is why sample financial statements and disclosure checklists exist. But sample financial statements and disclosure checklists do not define US accounting standards.

An important point here is that in most cases, the different sample financial statements and disclosure checklists from the Big 4 accounting firms used the same "line item labels", and more importantly these line items attract the same numerical value when applied in the preparation of a set of financial statements. The USFRTF reflects this and where there are differences in the line item labels, the taxonomy framework reflects a consensus of opinion.

Also, if desired, the Big 4 accounting firms or other stakeholders could create extension taxonomies to reflect labels and relationships they deem to be more appropriate than the USFRTF. And frankly, they likely will.

One vantage point to help you get your mind around what the USFRTF is that the taxonomy framework could be considered somewhat of a collection of concepts and relations which could be used to create a "big sample financial statement". But most of the sample financial statements certainly are not organized in the manner of the USFRTF. Nor are sample financial statements nearly as comprehensive as the USFRTF – the taxonomy framework is very comprehensive.



10.2.4. A Consensus The way a sample financial statement and disclosure checklist is typically created is decided internally within each of the individual Big 4 accounting firms. These sample statements and disclosure checklists are prepared by reference to the different accounting pronouncements applicable from US GAAP to each part of the sample and/or disclosure checklist.

But the USFRTF has a broader consensus; the Big 4 and regional accounting firms and many, many other financial reporting and accounting experts came to a consensus as to what should be in the USFRTF. Derived from this consensus is the single taxonomy framework instead of competing/conflicting taxonomy frameworks. While the USFRTF might not look like any of the Big 4 accounting firms sample financial statements or disclosure checklist, it reflects all of them because it is based on this broader consensus.

The USFRTF represents one way to create a taxonomy to represent US GAAP. And while the USFRTF is not the only way a company can report using US GAAP, it is one way a company can report. This is all that the USFRTF can be. All possible ways to report could not possibly be reflected in a single taxonomy framework. Reflecting all possibilities would render the taxonomy too confusing. However, the USFRTF can still be as flexible and dynamic as financial reporting by extending the taxonomy.

Again, this is a bit of an over simplification in order to make a point. The point is that there is only one, say, classified balance sheet format rather than every possible format for the classified balance sheet.

10.2.5. EDGAR® Another resource which was used to create the USFRTF was the SEC’s EDGAR system. EDGAR® Online®, Inc. has tools which can take the millions of financial statements filed with the EDGAR system, examine them, and then parse the information so it can be used to understand how companies actually report. How companies actually report is extremely good information in determining what is needed in the USFRTF.

EDGAR Online and others (University of Kansas, EDGARSCAN) have been writing software for many years trying to extract useful information from Edgar filings of public companies, this is a wealth of information. However, if it were possible to perfectly parse this information, XBRL and the USFRTF would not need to exist.

Very useful information has been gleaned from this process and these systems generate information which can be recycled into making the USFRTF better. For example, EDGAR Online has been able to generate XBRL instance documents (an XML document that contains the actual company report information in XBRL format) for almost 100,000 public companies (counting current and prior period filings). This information was used to generate an EDGAR Online "extension" to the USFRTF for areas where it fell short in meeting the needs of actual financial reporting practices. They basically have 100,000 XBRL instance documents which can be used to test the USFRTF.

This actual information is incredibly useful input in judging how well the USFRTF works, where it needs to be adjusted, etc.

10.2.6. Principles Based Accountants always need to exercise professional judgment in creating financial statements, whether they are prepared using standard financial statements, disclosure checklists, XBRL taxonomies, or other tools used for financial reporting.



10.2.7. Not a Standard Chart of Accounts The USFRTF certainly is not a "standard chart of accounts". Again, accountants need to always exercise professional judgment. XBRL is simply a method of expressing something, anything really, using a language which computers can understand. How the language is used is up to the users. XBRL is extensible. That is one of the primary requirements the users, which included accountants, placed on the technical people when creating XBRL.

Any company, any industry, or any accountant is free to use, or not use any taxonomy component or add any taxonomy component by extending the USFRTF. XBRL and the taxonomy framework are that flexible.

Users of the USFRTF are free to ask the accountants to justify why they added an extension or did not use the USFRTF as it exists. Frightening? Maybe. With the right of exercising professional judgment comes the responsibility to have and use good judgment. That is the role of a professional accountant.

Does XBRL provide clarity? Yes it does. Clarity as to what concept you intended to communicate, how the concept is mathematically calculated, etc. One thing that XBRL does do is reduce, but not necessarily eliminate, vagueness. The creator of the financial information communicates clearly, using concepts from the USFRTF or by adding a concept which they believe is appropriate to add, or adding relationships which they feel are appropriate to add. Analysts using this information can see very clearly which concepts have been used, how concepts add up.

The USFRTF does NOT require any company to report additional information. What it does is help see, very clearly, what was reported and allows a computer to use the information reported.

10.2.8. The "House of GAAP" XBRL does not cover everything in US GAAP. And there are common practices that are not included in accounting pronouncements issued by any standards body which are included in the USFRTF.

The taxonomy is about what is presented and disclosed in financial statements. US GAAP also covers recognition and measurement. The taxonomy generally does not cover recognition or measurement unless it relates to a method or basis of measurement that should be disclosed or assumptions made in making those measurements that should be disclosed.

Other concepts have an "XBRL" reference. These concepts (referred to as abstract concepts) are only for the convenience of presenting (referred to as the presentation link) the taxonomy in a visual, hierarchical format that accountants can easily understand. These concepts can never appear in an XBRL financial statement, called an instance document.

10.2.9. Industry Coverage Currently, the USFRTF does not cover all industries. Nor does it cover certain types of financial reporting such as reporting by not for profit entities, state and local governmental entities, or personal financial statements.

The following is a list of AICPA audit guides which will provide an idea of the different industries which exist:

AICPA Audit Guides USFRTF Taxonomy Agricultural Producers and Agricultural Cooperatives

Not provided



Airlines Not provided Banks and Savings Institutions us-gaap-basi Brokers and Dealers in Securities us-gaap-bd Casinos Not provided Common Interest Realty Associations Not provided Construction Contractors Not provided Credit Unions Not provided Employee Benefit Plans Not provided Entities with Oil and Gas Producing Activities us-gaap-og Federal Government Contractors Not provided Finance Companies Not provided Health Care Organizations Not provided Investment Companies us-gaap-im Property and Liabilities Insurance Companies

us-gaap-ins

Service Organizations Not provided Not-for-Profit Organizations Not provided State and Local Governmental Units Not provided Personal Financial Statements Not provided

The XBRL-US Domain Working Group is currently responsible for creating new taxonomy framework pieces for the industries identified above. Although a few additional taxonomies are in development, there is no known master plan for the building out of the USFRTF to cover all these industries.

10.2.10. What is the USFRTF? With the background provided above, we now venture to define what the USFRTF is from an accountant's perspective.

The USFRTF is one consensus-based method of "electronically" classifying concepts and formats that may be used in presenting and disclosing financial information under US GAAP. It covers both US GAAP and common practices used for US financial reporting.

The language, XBRL, is a language which is understandable to both humans and computers. The USFRTF does not define new accounting concepts. The USFRTF does not extend or reduce the professional judgment needed by accounting professionals who are responsible for creating financial statements under US GAAP.

10.2.11. Some Things Accountants Should Understand Taxonomies are important to accountants; accountants make up a large majority of who will be using these taxonomies. Therefore, accountants need to thoroughly understand these taxonomies. This is particularly true because the USFRTF is really still being created and is open for input.

The following are a few things that accountants really need to understand in order to contribute to making sure we have the correct XBRL taxonomies for the needs of the US financial reporting supply chain. These points are summarized below and are not about making any sort of judgment about the USFRTF or what is appropriate. This is the responsibility of the accounting profession and other participants in the financial reporting supply chain.

What is outlined here are a number of aspects that accountants need to understand so that they can determine if these aspects are applied correctly in the USFRTF to increase the probability that the USFRTF is appropriate to use for financial reporting.



The goal here is to empower the accountants to better read, understand, and contribute to the improvement of the USFRTF. If users do not understand these concepts, they will not understand the USFRTF appropriately.

10.2.11.1. One or Many We have to use two technical terms here in order to make a very important point: XBRL items and XBRL tuples. Items and tuples will be discussed in further detail later but there is one very important difference between these two "building blocks" of taxonomies.

When you put an XBRL item (such as “Land”) in a taxonomy, you can use the given reporting concept once and only once for a context when you create an XBRL instance document. An XBRL context represents a reporting time period for a specific entity and for a specific reporting scenario.

When you put an XBRL tuple in the taxonomy, you can report an unlimited number of the given reporting concept for a specific context. For example, "Class of Common Stock" is a tuple which has a number of items included within the tuple. Since "Class of Common Stock" is a tuple, you can report an unlimited number of different classes of common stock.

A critical point to understand with items and tuples is this: Are the concepts in the taxonomy which are items properly designated items; and the concepts which are tuples properly designated tuples? If not, then the taxonomy will not be usable as required by its users.

The choice of whether to express a concept as an item or as a tuple when creating a taxonomy can be a “science”, with reporting concepts falling into one category or the other. However, sometimes there are shades of gray involved and ultimately the desired result will determine the choice between these two options.

10.2.11.2. Same Concept Concepts should be defined in the USFRTF taxonomy only once. For example, "Net Income" should be defined once. This concept is in the USFRTF. Now, this concept is used in multiple places in the framework: on the income statements, in the statement of equity, in the cash flow statement, and many, many other places.

If, however, the concept is NOT actually the exact same reporting concept in all the places it occurs within a taxonomy, it should NOT be defined only once. Instead, they should be defined as separate concepts and appear where necessary in the taxonomy.

This distinction is critical. If a concept is defined once, and the concept is used in two different places but the values for a single specific context (i.e. period of time) could actually be different, then the taxonomy will not work unless the concepts are broken out separately in the taxonomy.

If a taxonomy author is unsure whether to assign the same element or not for a reporting concept that appears in multiple places within a taxonomy, the least risky choice is to create two different concepts.

10.2.11.3. Comparability XBRL is comparable to the extent that users of XBRL in a certain situation desire to have comparability. Comparability is not an XBRL issue, it is a domain issue; how much comparability does a specific domain, or use, of XBRL desire?



In the financial reporting supply chain, many dynamics are at work. Analysts need to analyze corporate report data. Comparability helps them, as it helps them make timely and accurate comparisons. Some companies like comparability while others don’t…for various reasons.

The financial reporting supply chain which uses the USFRTF will determine the comparability possible with the USFRTF by how they build the taxonomy framework. This will be driven by the market, as it is driven by the market now. In general, XBRL is capable of any level of comparability.

Comparability is a very emotional issue which people tend to turn into an XBRL technical issue. The reality is that comparability is a domain issue which will be determined by the domain. Coming to a consensus will likely involve much emotion and take many years to reach.

XBRL can handle any level of comparability a given domain throws at it, from “closed loop” systems such as the Federal Deposit Insurance Corporation (FDIC) implementation of XBRL to more market driven systems such as the Security and Exchange Commission’s (SEC) Voluntary Filing Program.

Creating taxonomies that leverage standard dimensions and/or standard industry schemes enhance comparability. Not having standard approaches does not mean that comparability cannot be achieved; it just means it will be harder. The technical aspects of comparability and the emotional aspects of comparability need to be separated.

10.2.11.4. Dialog and Balance XBRL can facilitate a clearer dialog between standard setters, accountants, analysts/regulators and reporting entities. Financial reporting pronouncements are fairly detailed and complex. XBRL helps in this communication by forcing the communication to be more explicit, as well as allowing the communications to be expressed in a global standard way. XBRL allows these parties to communicate at a very detailed, clear level.

This communication is not new; communication has always existed in the financial reporting supply chain. However, XBRL is raising the possibility of communicating at an even higher (and more efficient) level of detail. That possibility never really existed before in a global, standard way. XBRL taxonomies play a very important part in helping achieve this level of communication.

Also, some information technology tools or processes could be adopted by the accounting profession to help make pronouncements clearer throughout the financial reporting supply chain. For example, when software is created, there also tends to be created something called a "conformance suite". A conformance suite exercises the software to ensure that it is operating as intended. Creating an XBRL taxonomy and instance documents based on existing pronouncements, such as the current USFRTF has done, actually helps users to understand and use those pronouncements, and, more importantly, will be available for potential new pronouncements.

The process of using a taxonomy to create real financial statements helps detect inconsistencies so they can be resolved. Let's look at an example of this in the creation of another financial reporting taxonomy. In creating the International Financial Reporting Standards – General Purpose (IFRS-GP) taxonomy, a number of inconsistencies were detected in the existing International Accounting Standards (IAS)/IFRS standards. In many cases, the inconsistencies will be (are) interpreted consistently by humans who can figure things out even if they are somewhat inconsistent. However, there are still inconsistencies which are open



for interpretation. This does not include those where room was intentionally left for interpretation; this is inconsistency which forces interpretation where interpretation was not intended. Computers are very, very bad at dealing with inconsistencies; in fact, they cannot operate with inconsistencies as humans can and achieve a reasonable, consistent result.

There are two quick examples which arose when creating the IFRS-GP taxonomy to make the point more clearly. The IFRS/IAS standards define the concept "Finance Costs" but it does not provide an example or clearly state what makes up the details/what to include in finance costs. As a result, this was one of the harder areas of the IFRS-GP taxonomy to create, as it was far harder to agree on what goes into the detail of the line item "Finance Costs". Guidance could have been much more clear.

The second issue involved "Minority Interest" and "Subscribed Capital", two components of equity. These line items moved around the taxonomy for several years and it was hard to agree where they should appear in the financials.

Another interesting thing which occurred while creating the IFRS-GP taxonomy was the dialog between financial institutions and the taxonomy creators, indirectly through one of the central banks. The taxonomy was initially created based upon interpreting the standards as written. However, discussions with financial institutions made it clear that the financial institutions could not report information in a certain manner; a different approach with the same end result would have been more practical. As such, the taxonomy was modified.

The dialog between standard setters, accountants, analysts/regulators and reporting entities is not new. However, it can be more detailed as a result of XBRL. Creating taxonomies to express new proposed standards help test the standard and make it crystal clear what the standard is asking for. The ultimate step will be realized when standard setters and regulators use XBRL when communicating new pronouncements to the financial reporting supply chain.

10.2.11.5. Computers Don’t Fully Understand the Taxonomy Computers don’t fully understand a taxonomy. Now, this is a quite an odd statement, given that the XBRL version of the taxonomy is something a computer is supposed to understand. But let me explain. To a computer, there is no real differentiation between many pieces of the taxonomy at this point. A computer has no idea that "Cash and Cash Equivalents" is a balance sheet line item and that "Net Income" goes on the income statement. It also does not know that "Intangible Assets Policy" is really a policy. Humans think computers can understand these concepts because the word "Policy" is included in the term "Intangible Assets Policy". Unfortunately, computers cannot, or should not.

The reality is that computers are pretty dumb, they need to be told everything about every aspect which they are supposed to understand. They are smart in areas where they are made smart.

Computers do understand XBRL, if they have XBRL processing software. XBRL processors understand XBRL concepts and will know that "Cash and Cash Equivalents" and "Net Income" and "Intangible Assets Policy" are all reporting concepts. And, computers will even know some things about the concept, such as, whether it is a number, a piece of text, a debit or credit, or what type of period it relates to.

In order to have additional meaning in the taxonomy, which XBRL technically provides and which people will soon do, you have to add that meaning. The definition linkbase functionality of XBRL is a very powerful tool, but as of now,



unused in the USFRTF. By adding things like a definition linkbase, computers can understand more about the components of the taxonomy.

For example, there is no concept of a "Balance Sheet" in XBRL, but there could be if it is added. There is no concept of an "Accounting Policy", but there could be, and "Intangible Assets Policy" could be included in the collection of policies.

The point is that much of this meaning does not exist yet, more will be added. Base information does exist. And as the meaning is added, XBRL will be even more powerful. What is added will determine how powerful it will be. This is why things such as the "Link Role Registry" (LRR) are important, even though you might not understand completely what the Link Role Registry is.

10.2.12. In Summary XBRL is a relatively new tool which accountants and other participants in the financial reporting supply chain have at their disposal. Even though relatively new, XBRL will exist far into the future.

Accountants need to understand XBRL in order to harness its power. Learning about the basics of XBRL is the first step to understanding where it is working and where it is not, and then correcting the USFRTF to work as required.

XBRL needs to work as financial reporting currently works today; changing financial reporting en masse to meet the needs of XBRL is not acceptable, nor would it be tolerated in the marketplace. There may be certain aspects of financial reporting that will likely change over time as a result of the use of XBRL. However, the USFRTF in no way changes financial reporting, other than provide a method of expressing financial information, defined by existing financial reporting pronouncements in an electronic format which is readable by computer software.

10.3. Physical Location of Framework

10.3.1. URL All the taxonomies that make up the USFRTF can be found at the XBRL-US Web site (http://www.xbrl.org/us) by selecting "US GAAP Taxonomies". This brings up the following web page:



On this page is a listing of all the approved, or released and usable, USFRTF taxonomies.

10.3.2. File Structure If you look at the directory structure of the taxonomies, they look like the following:



10.3.3. USFRTF Files The following is a summary of the URLs of each taxonomy file:

Namespace Prefix

FileType

FullURL

usfr-fstr XSD http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28.xsd usfr-fste XSD http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28.xsd us-gaap-im XSD http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28.xsd usfr-fstr Labels http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28-label.xml usfr-fste Labels http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28-label.xml usfr-fstr Presentation http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28-

presentation.xml usfr-fste Presentation http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28-

presentation.xml usfr-fste References http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28-

reference.xml usfr-fstr References http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28-

reference.xml us-gaap-basi XSD http://www.xbrl.org/us/fr/common/fstr/2005-02-28/usfr-fstr-2005-02-28.xsd usfr-fstr XSD http://www.xbrl.org/us/fr/common/fstr/2005-02-28/usfr-fstr-2005-02-28.xsd us-gaap-im XSD http://www.xbrl.org/us/fr/common/ime/2005-06-28/usfr-ime-2005-06-28.xsd



us-gaap-im XSD http://www.xbrl.org/us/fr/common/pte/2005-02-28/usfr-pte-2005-02-28.xsd usfr-pte XSD http://www.xbrl.org/us/fr/common/pte/2005-02-28/usfr-pte-2005-02-28.xsd usfr-pte Labels http://www.xbrl.org/us/fr/common/pte/2005-02-28/usfr-pte-2005-02-28-label.xml usfr-pte Presentation http://www.xbrl.org/us/fr/common/pte/2005-02-28/usfr-pte-2005-02-28-

presentation.xml usfr-pte Reference http://www.xbrl.org/us/fr/common/pte/2005-02-28/usfr-pte-2005-02-28-reference.xmlusfr-fstr XSD http://www.xbrl.org/us/fr/common/ptr/2005-02-28/usfr-ptr-2005-02-28.xsd usfr-ptr XSD http://www.xbrl.org/us/fr/common/ptr/2005-02-28/usfr-ptr-2005-02-28.xsd usfr-ptr Calculation http://www.xbrl.org/us/fr/common/ptr/2005-02-28/usfr-ptr-2005-02-28-calculation.xmlusfr-ptr Presentation http://www.xbrl.org/us/fr/common/ptr/2005-02-28/usfr-ptr-2005-02-28-

presentation.xml us-gaap-basi XSD http://www.xbrl.org/us/fr/gaap/basi/2005-02-28/us-gaap-basi-2005-02-28.xsd us-gaap-basi Calculation http://www.xbrl.org/us/fr/gaap/basi/2005-02-28/us-gaap-basi-2005-02-28-

calculation.xml us-gaap-basi Labels http://www.xbrl.org/us/fr/gaap/basi/2005-02-28/us-gaap-basi-2005-02-28-label.xml us-gaap-basi Presentation http://www.xbrl.org/us/fr/gaap/basi/2005-02-28/us-gaap-basi-2005-02-28-

presentation.xml us-gaap-ci XSD http://www.xbrl.org/us/fr/gaap/ci/2005-02-28/us-gaap-ci-2005-02-28.xsd us-gaap-ci Calculation http://www.xbrl.org/us/fr/gaap/ci/2005-02-28/us-gaap-ci-2005-02-28-calculation.xml us-gaap-ci Presentation http://www.xbrl.org/us/fr/gaap/ci/2005-02-28/us-gaap-ci-2005-02-28-

presentation.xml us-gaap-im XSD http://www.xbrl.org/us/fr/gaap/im/2005-06-28/us-gaap-im-2005-06-28.xsd us-gaap-im Calculation http://www.xbrl.org/us/fr/gaap/im/2005-06-28/us-gaap-im-2005-06-28-calculation.xmlus-gaap-im Presentation http://www.xbrl.org/us/fr/gaap/im/2005-06-28/us-gaap-im-2005-06-28-

presentation.xml us-gaap-ins XSD http://www.xbrl.org/us/fr/gaap/ins/2005-02-28/us-gaap-ins-2005-02-28.xsd us-gaap-ins Calculation http://www.xbrl.org/us/fr/gaap/ins/2005-02-28/us-gaap-ins-2005-02-28-

calculation.xml us-gaap-ins Labels http://www.xbrl.org/us/fr/gaap/ins/2005-02-28/us-gaap-ins-2005-02-28-label.xml us-gaap-ins Presentation http://www.xbrl.org/us/fr/gaap/ins/2005-02-28/us-gaap-ins-2005-02-28-

presentation.xml usfr-ar XSD http://www.xbrl.org/us/fr/rpt/ar/2005-02-28/usfr-ar-2005-02-28.xsd usfr-ar Labels http://www.xbrl.org/us/fr/rpt/ar/2005-02-28/usfr-ar-2005-02-28-labels.xml usfr-ar Presentation http://www.xbrl.org/us/fr/rpt/ar/2005-02-28/usfr-ar-2005-02-28-presentation.xml usfr-ar References http://www.xbrl.org/us/fr/rpt/ar/2005-02-28/usfr-ar-2005-02-28-references.xml usfr-mda XSD http://www.xbrl.org/us/fr/rpt/mda/2005-02-28/usfr-mda-2005-02-28.xsd usfr-mda Labels http://www.xbrl.org/us/fr/rpt/mda/2005-02-28/usfr-mda-2005-02-28-label.xml usfr-mda Presentation http://www.xbrl.org/us/fr/rpt/mda/2005-02-28/usfr-mda-2005-02-28-presentation.xml usfr-mda References http://www.xbrl.org/us/fr/rpt/mda/2005-02-28/usfr-mda-2005-02-28-reference.xml usfr-mr XSD http://www.xbrl.org/us/fr/rpt/mr/2005-02-28/usfr-mr-2005-02-28.xsd usfr-mr Labels http://www.xbrl.org/us/fr/rpt/mr/2005-02-28/usfr-mr-2005-02-28-labels.xml usfr-mr Presentation http://www.xbrl.org/us/fr/rpt/mr/2005-02-28/usfr-mr-2005-02-28-presentation.xml usfr-sec-cert XSD http://www.xbrl.org/us/fr/rpt/seccert/2005-02-28/usfr-seccert-2005-02-28.xsd usfr-sec-cert Labels http://www.xbrl.org/us/fr/rpt/seccert/2005-02-28/usfr-seccert-2005-02-28-labels.xml usfr-sec-cert Presentation http://www.xbrl.org/us/fr/rpt/seccert/2005-02-28/usfr-seccert-2005-02-28-

presentation.xml usfr-sec-cert References http://www.xbrl.org/us/fr/rpt/seccert/2005-02-28/usfr-seccert-2005-02-28-

references.xml

There are a total of 53 files included in the USFRTF (this includes the broker-dealer taxonomy)

10.3.4. Relations Between USFRTF Taxonomies The following diagram explains the relationships between the different taxonomies.



A document, "US Financial Reporting Taxonomy Framework" summarizes information about the USFRTF. It is located at the following URL:

http://www.xbrl.org/us/USFRTF/2005-02-28/USFRTF%202005-02-28%20Explanatory%20Note.htm

This document:

• Explains the US Financial Reporting Taxonomy Framework, provides an overview of its components and structure, as well as plans for future components.

• Describes significant design decisions, updates from previous versions, etc.

The above summary document states, "The US Financial Reporting Taxonomy Framework is a collection of XBRL taxonomies that will be used to express the financial statement-based reports of both public and private companies across all industry sectors."

10.4. Components of Framework First we will take a look at the components of the USFRTF. Then we will look at the relationships between the components.

The framework is broken down into components or "layers". These layers include:

• Add-on taxonomies

• Common terms

• Common relationships

• Industry relationships

Note that all components of the USFRTF are compliant with the XBRL 2.1 specification and FRTA (Financial Reporting Taxonomies Architecture) version 1.0 (more information on FRTA can be found on the XBRL International Web site).

10.4.1. Add-on Taxonomies Layer Add-on taxonomies are stand alone taxonomies typically used by those creating instance documents. For example, all audited financial statements have an accountants report and the USFRTF contains an Accountants Report taxonomy.



Those who wish to use these add-on taxonomies can attach them to their extension taxonomy or to their instance document.

10.4.2. Common Terms Layer (Common Concepts Layer) The common terms layer are basically building blocks for other taxonomies, usually industry taxonomies. For example, the term "Net Income" is a commonly used term, whereas "Aircraft" is a term which is specific (for the most part) to the airline industry. This set of taxonomies contain schema (.XSD) files with concepts, labels (in the label linkbases) for those concepts, and reference linkbases with references to accounting pronouncements for those concepts. Also, in many cases, documentation (such as human readable definitions) is also provided for these concepts.

10.4.3. Common Relationships Layer The common relationships layer is again building blocks, but for presentation and calculation relationships, rather than the concepts themselves. If the relationships are common across many industries, they are typically expressed here.

10.4.4. Industry Concepts Layer The industry concepts layer contains concepts which are unique for a specific industry. For example, "Aircraft" is a concept unique to the airline industry. Rather than burdening other industries with this term, it is defined within the industry concepts schema, rather than the common terms schema shared by all industries.

10.4.5. Industry Relationships Layer The industry relationship layer expresses industry-specific presentation and calculation relationships. The industry relationships layer typically uses the common concepts layer and common relationships layer taxonomies and builds upon them for a specific industry, such as "Airlines".

10.4.6. Summary of Existing Components The following is a summary of the existing components of the USFRTF. The components are broken down by layer. For each component, the namespace prefix, name of the taxonomy, the status of the taxonomy, and a brief description of the taxonomy are provided.

This summary contains only taxonomies which are approved (or final and released), are drafts, or are currently planned.

Namespace Prefix

Name

Status

Description

Common Layer Taxonomies

usfr-pte Primary Terms Elements Approved Contains common terms used by many industries.

psfr-ptr Primary Terms Relationships

Approved Contains common relationships used by many industries.



usfr-fst Financial services Approved Common terms used within financial services sector.

Add-on Taxonomies

usfr-sec-cert SEC Certification Approved Contains concepts commonly used with the officer's certification report as mandated by Sarbanes-Oxley Act of 2002.

usfr-mr Management Report Approved Contains terms which are used within the management report which typically accompanies audited financial statements.

usfr-ar Accountants Report Approved Contains terms which are used within the independent accountants' report.

usfr-mda Management Discussion and Analysis

Approved Contains terms commonly used within the annual report where a company's management provides analysis on results of operations, financial positions, and issues.

Industry Layer Taxonomies

us-gaap-ci Commercial and Industrial Companies

Approved Concepts and relationships to allow commercial and industrial entities to express their financial statements.

us-gaap-basi Banking and savings institutions

Approved Concepts and relationships to allow banking related entities to express their financial statements.

us-gaap-ins Insurance Entities Approved Concepts and relationships to allow insurance related entities to express their financial statements.

us-gaap-im Investment Management

Approved Concepts and relationships to allow investment management related entities such as mutual funds to express their financial statements.

us-gaap-bd Broker-Dealers DRAFT Concepts and relationships to allow insurance related entities to express their financial statements.



us-gaap-og Oil & Gas Under development

Concepts and relationships to allow oil and gas related entities to express their financial statements.

Each of the taxonomies summarized above are a part of the USFRTF. From the summary of all taxonomies in the USFRTF on the XBRL-US web site, users can navigate to a summary page for a specific taxonomy. This web page which serves as a summary of information related to that specific taxonomy. For example, look at the line below for "Commercial and Industrial":

If you click on the link for this taxonomy, you will be taken to the following summary page at the following URL:

http://www.xbrl.org/us/fr/gaap/ci/2005-02-28/us-gaap-ci%20Summary%20Page.htm

This summary page is somewhat of a "starting point" for the taxonomy. The summary page contains the following information:

• General information about the taxonomy.

• Location of the physical files included in the taxonomy.

• Downloadable copies of the taxonomy files for local use.

• Explanatory Notes which is a narrative which describes the taxonomy. It also contains disclaimers, terms and conditions of use, and other important legal stuff which should be considered.

• Printouts of the taxonomy.



• Sample instance documents provided with the taxonomy including various XSLT style sheets to render the instance documents into a human readable format.

• "Proof" instance documents (included in the samples) which contains basically every concept in the taxonomy and is used to test every calculation of the taxonomy.

• ZIP file which contains taxonomy files, printouts, samples, etc. which can be downloaded and used locally.

• Summary of errors discovered and reported.

It is highly likely that these summary pages become somewhat insignificant to actual users of the taxonomy. You may never need to know or use information about the taxonomy at this level. It is highly likely that software vendors and others will better organize this information so it is far more usable by the average CPA but for the time being, this is where all the information about each of the taxonomies exist.

The USFRTF can be used from the Internet, but it is more than likely that you will download a copy of the taxonomies and use the version on your local hard drive. A local version of the taxonomy ensures you don’t have to download it every time you desire to use it and thus should increase performance when using XBRL-enabled software applications.

10.4.7. Probable Future Components To get a better idea of the taxonomy framework, we will speculate here about the future components of the USFRTF. The following speculates on additional taxonomies which will be included in the USFRTF.

Namespace Prefix

Name

Status

Description

Industry Layer Taxonomies

us-gaap-agri Agricultural Producers and cooperatives

Will likely be added

us-gaap-air Airlines Will likely be added

us-gaap-cas Casinos Will likely be added

us-gaap-cira Common Interest Realty Associations


us-gaap-cc Construction Contractors


us-gaap-cu Credit Unions Will likely be added

us-gaap-eb Employee Benefit Plans Will likely be added

Federal Government Contractors

Probably will not be a separate taxonomy

us-gaap-fc Finance Companies Will likely be added

us-gaap-hc Health Care Organizations




us-gaap-so Service Organizations Will likely be added

us-gaap-np Not for profit

Organizations Will likely be added, but not in this framework

us-gaap-slgu State and Local Governmental Units

Will likely be added, but not in this framework

us-gaap-pf Personal Financial Statements

Will likely be added, but not in this framework

The last three on the list, Not for Profit Organizations, State and Local Governmental Units, and Personal Financial Statements deserve a bit of discussion. It is hard to determine exactly how these three taxonomies will fit within the USFRTF model since USFRTF is currently focused on public/for profit companies. There are three possibilities:

• The first possibility is that they will be tightly woven into the existing foundation, such as using the primary terms taxonomy. This approach leads to two things. First, that the term "Cash and Cash Equivalents", for example, would have one definition in all of US financial reporting. There are those who value this. But that comes at a price. If you want "Cash and Cash Equivalents", you get EVERYTHING ELSE also. All of it. For example, take the case of the potential negative impact this could have as it relates to a user of the personal financial statements. Personal financial statements tend to be rather simple but this approach means that the user has to wade through all the common terms used in the reporting of public companies just so there can be one concept for "Cash and Cash Equivalents".

• The second possibility is that each of the last three taxonomies would NOT share the primary concepts, but would create separate physical schema files for each of the taxonomies, each most likely defining "Cash and Cash Equivalents". This makes using each taxonomy simpler, as you are not burdened with wading through thousands of concepts which you would never use. However, would this mean that you cannot compare say the City of New York's "Cash and Cash Equivalents" (a local government), Microsoft's cash (a public company), and John Doe's cash? It does not mean that at all. Mappings can easily be created between different physical schema files allowing comparisons across taxonomies.

• The third option is to split the primary terms taxonomy into those which would be shared by all taxonomies, and those which would not.

One additional final point is worth reinforcing. Currently, the USFRTF primarily covers financial reporting by public companies. It does not cover financial reporting by private companies. For example, a small restaurant which is a sole proprietorship or a CPA partnership are not covered by USFRTF. Will the existing taxonomies be expanded to cover private companies, or will separate taxonomies be built for the private sector? This has not been determined.

What ultimately drives how these taxonomies, or drives how these taxonomies should be created, is how they will be used and the user experiences of those using these taxonomies, all things considered. Theoretically, it would be great to



have one concept "Cash and Cash Equivalents". However, from a practical perspective, it is a simple process to create a mapping to express that they are the same and create separate physical files.

All this will be worked out over time. At this time, the taxonomies have not been used enough to know the right answers to every question. Using them, and then refactoring the taxonomies based on user feedback will likely be in the cards for the USFRTF as it evolves.

10.5. Relationship of Physical Files The USFRTF contains a number of taxonomies that are used to create an industry taxonomy such as US GAAP CI. Each taxonomy contains a number of different physical files. This section will describe these files and how they relate to one another.

Some of the files are related and have physical mechanisms to express that relationship. For example, the XML Schema <import> element physically relates the files in a precise fashion so that an XML parser or XBRL processor can navigate through them consistently and completely. In general, there are four ways taxonomy files can be related:

• <import> element from one schema file to another schema file

• <schemaRef> element from an instance document to a schema file.

• <linkbaseRef> element from an instance document or schema file to a linkbase.

• <locator> HREF attribute from a linkbase locator to a schema file.

We will look at a few known issues in order to understand how these physical relationships work.

10.5.1. Issues with Relations Each of these different linking mechanisms has different "features". These features can be positive (desirable), or negative (undesirable). The important thing when creating taxonomies is to have the right combination of physical relatedness.

Additionally, files can be intended to be physically related, but not actually physically related in a taxonomy. The relationships can be put together in a company's extension taxonomy or in an instance document.

For example, currently in the US GAAP CI "Commercial and Industrial Companies" taxonomy, the presentation and calculation relationships exist for both the direct and indirect versions of the cash flows statement. A company would never have both such cash flows statements; they would have either direct or indirect.

Another approach to building taxonomies is to not have components such as presentation links and calculation links which COULD be used related to a schema file and instead provide them as modularly as possible and let the users of the taxonomy "wire them together" (physically link them) as desired.

This is the approach used by the IFRS-GP taxonomy, and it is the approach which the USFRTF will likely move toward. This approach has been called "the window" taxonomy approach (as you provide a window into the concepts, based on the linkbases) or an "ala carte" or "palette" approach. This approach is characterized by creating lots of smaller components (such as having the direct and indirect cash slows statements presentation and calculation linkbases in separate files) and then “linking them” together. A user of the taxonomy can then ultimately



hook the smaller components they desire to use either to their company extension taxonomy or to their instance document.

Please keep in mind that this is not how the current version of the USFRTF is created, but to some degree this can be achieved and in fact will be explained later. In summary, this approach simply ignores the schema files such as the Commercial and Industrial Companies schema (us-gaap-ci-2005-02-28.xsd) which only contains links to the linkbases and instead references the linkbase files themselves such as (us-gaap-ci-2005-02-28-calculation.xml) as required by the user. The problem still exists that both the direct and indirect cash flows statement calculations links are in the same file. But these can be separated out in the future. Users can separate them out now by simply creating their own calculation linkbases, for example.

10.5.2. Issues with Extended Link Role Definitions Another issue exists with the USFRTF related to extended link roles which will likely be addressed in future versions. Currently, the extended link roles used by each taxonomy are defined by each taxonomy. For example, the extended link role "http://www.xbrl.org/us/fr/ lr/role/StatementFinancialPosition" is defined by the us-gaap-ci, us-gaap-basi, us-gaap-in, us-gaap-im (it is actually different, but this is a balance sheet, it is just called something slightly different), etc.

An alternative would be to create one file which defines all these extended link roles which are needed by the entire USFRTF, or perhaps modularize it into two or a few files. This creates more consistency between the extended links.

10.5.3. USFRTF Current Status Having explained a few issues and how they might be worked around or resolved in the future, we will like at how files are physically related now. We will do this by looking at one taxonomy, the "Commercial and Industrial Companies" taxonomy, or as we will refer to it, the “CI” taxonomy.

The "core" of a taxonomy is its schema file(s). For example, the schema file for the taxonomy CI taxonomy is "us-gaap-ci-2005-02-28.xsd". This file is located at the following URL: http://www.xbrl.org/us/fr/gaap/ci/2005-02-28/us-gaap-ci-2005-02-28.xsd.

The schema file defines concepts used within the taxonomy, hooks to other schema files which define concepts used, or hooks to linkbases used by the taxonomy. In the case of the Commercial and Industrial Companies taxonomy, the schema file:

• Uses the <import> element to connect to the primary terms taxonomy, usfr-ptr-2005-02-28.xsd,

• Uses the <linkbaseRef> to physically link to the set of presentation links, us-gaap-ci-2005-02-28-presentation.xml,

• Uses the <linkbaseRef> to physically link to the set of calculation links, us-gaap-ci-2005-02-28-calculation.xml,It defines a number of extended link roles used in the presentation and calculation linkbases.

It also, like all taxonomy files, imports two schemas used by XBRL, xbrl-instance-2003-12-31.xsd and xbrl-linkbase-2003-12-31.xsd. This is required as per the XBRL Specification.

A couple of things are worth noting. The CI taxonomy defines no concepts; all concepts come from the primary terms taxonomy.



The calculation and presentation links are physically hooked to the CI schema. In the future, it is highly likely that the CI schema may not even exist, and the CI single presentation and calculation linkbases, each one separate file, will likely be 50 or so separate components, each component used if desired, but the user is not burdened by unneeded presentation and calculation relationships.

Any more discussion on relationships would tend to get very technical, so we will stop here. Additional issues related to the relationships between files which are important for accountants to understand will be addressed later in this document.

The important takeaways from this discussion of the physical relationships between files are the following:

• Taxonomies typically contain one or more schema files and linkbase files…all of which are physical files.

• The smaller the number of files, the less control users have over the components of the files. If you have one file with everything in it, and you need one small set of stuff from the file, if you use that file, you get everything in that file. If you have a larger number of smaller files, you have more files to look through to find what you need, but when you find what you need, you are not burdened by other information which tends to clutter or obscure the smaller set of information you were looking for.

• Taxonomies are made up of schema files (XSD) and linkbases. We will discuss the different types of linkbases and what they do later.

10.6. USFRTF (CI Taxonomy) Summary Information The following summary information relating to the taxonomy provides an overview of the USFRTF CI taxonomy:

• Has about 53 physical files which make up the official USFRTF (this does not include printouts, etc.

• Defines 3,066 concepts,

• Defines 37 extended link roles defined, but some of these are defined multiple times in different taxonomies,

• Contains 44 tuples,

• Defines 1 custom type (data types),

• There are 10,394 labels (about 3.3 labels per concept which includes a standard label, documentation, terse label, etc.)

Since all this will be explained in later sections, the above is simply a summary of statistics relating to the CI taxonomy.

The CI taxonomy is XBRL 2.1 compliant, FRTA compliant, and the sample instance documents provided with it are FRIS compliant. The sample instance documents provided with the CI taxonomy serve as an example of how instance documents look when prepared by US public commercial and industrial like companies.

The components of the taxonomy will be described in significantly more detail later in the document.



10.7. Synchronization to US GAAP This version of the CI taxonomy is tied to US GAAP, sometimes called "the house of GAAP".

The table below shows the accounting literature covered in the USFRTF:

Publisher Publication Abbreviation FASB Accounting Principles Board Opinion APB FASB Statement of Financial Accounting Standard FAS FASB FASB Interpretation FIN FASB FASB Technical Bulletin FTB FASB Emerging Issues Taskforce EITF FASB Implementation Guide Q&A FASB FASB Staff Position FSP FASB Current Text CT FASB Accounting Principles Board Statements APS FASB FASB Financial Accounting Concepts CON AICPA Accounting Research Bulletin ARB AICPA AICPA Opinion and Interpretation AICPA Industry Audit and Accounting Guide AAG AICPA Statement of Position SOP AICPA Practice Bulletin PB AICPA AICPA Accounting Interpretation AIN AICPA AICPA Accounting Principles Board Statement AICPA AICPA Issues Papers AICPA AICPA Technical Practice Aids TPA SEC Regulation S-X SX SEC Article 9 ART 9 SEC Article 4 ART 4 SEC Regulation S-K SK SEC Regulation S-B SB SEC Regulation S-T ST SEC Staff Accounting Bulletins SAB SEC Regulation T Reg T SEC Staff Position SP SEC Financial Reporting Release FRR SEC Staff Legal Bulletin SLB SEC SEC Industry Guide OTS Federal Regulation FR

10.8. State and Maturity of the USFRTF Although the USFRTF has existed in many forms over the past several years, this version of the framework is really the first usable version. In the past, XBRL tools were not mature enough to properly test the taxonomies. All previous versions of the taxonomy should be considered “early prototypes” and thus abandoned in favor of the current version.

With this version of the USFRTF, a significant amount of testing has gone into creating the taxonomy. In many (but not all) of the USFRTF taxonomies, the calculation and tuples were tested to ensure they "behave" as desired by creating "sample" instance documents to test the taxonomy prior to releasing it.



However, the real test of the taxonomy will be when hundreds of companies are reporting their financial information using the USFRTF. This "stress testing" of the framework in the real world will help ensure it was built and operates as desired. During the creation of the USFRT a number of instance documents were created to test the taxonomy. Although helpful, the reality is the taxonomy is still fairly new and untested in the marketplace.

As with any work in progress, there are still some issues related to the taxonomy. It will likely never be perfect but it will be as good as humans can get it given the current maturity level of XBRL and XBRL software and related tools.

The importance of the USFRTF taxonomies should not be overlooked. In the early stages of XBRL, the USFRTF was the first set of taxonomies addressed by the consortium. These taxonomies blazed a trail when there was not even a trail to follow. More recently, the USFRT was the first taxonomies taken through the XBRL International Domain Working Group approval process, helping other taxonomy builders learn from the process as well as helping improve the process itself. Does being first mean that it reflects the way it should be built? Although still in its infancy, the use of the taxonomy in the marketplace will ultimately answer that question.

So, do the regulators, accountants, reporting entities, and consumers of information have what they need from the USFRTF? That question can only be answered through using the taxonomy to see where it works and where it does not. Only then will all of the participants in the financial reporting supply chain be able to prove that the taxonomy as it exists is the taxonomy required by the market.

The following are some specific examples of issues which remain unanswered in order to provide a sense of the financial reporting issues which are still to be answered through making use of the taxonomy in a real world environment:

• "Property, Plant and Equipment" is a commonly used line item on a balance sheet; however, the taxonomy defines several classes of Property, Plant and Equipment: "Land", "Building", etc. The issue is would it be better to simply define the concept "Property, Plant and Equipment" and offer no additional detail classes, or should the taxonomy offer a reasonable list of detail classes for "Property, Plant and Equipment" as it currently exists. If the latter is true, is the list provided the right detailed list, or are their additional classes that are required? Will accountants agree that the list provided is a good list?

• The same issue as above exists for "Identifiable Intangible Assets", "Accrued Expenses", and other similar sub classes of financial reporting information.

• If a company using the CI taxonomy is, say, an airline and wants to add the concept "Airplanes" as a class of "Property, Plant and Equipment" as part of their extension taxonomy, the process is more complex than just adding a single element and involves the following:

o The concept "Airplanes" must be added to the taxonomy,

o The measurement basis concept for airplanes must be added

o The depreciation method concept for airplanes must be added

o The estimated useful life concept for airplanes must be added

There are better ways of expressing these "properties" (or meta-data) of a class of Property, Plant and Equipment. This same issue exists for other parts of the USFRTF.



• The financial statements of conglomerates (hybrids) which have the characteristics of multiple industries cannot be easily expressed with the current USFRTF and thus an extension taxonomy must be created.

• Movement analysis calculation relations cannot be fully expressed in the taxonomy as XBRL cannot express cross-context (time period) relationships. This deficiency is currently being addressed by the creation of the formula linkbase specification (add-on functionality to the XBRL 2.1 Specification) which is discussed later in this document.

• At times, concepts are included in the taxonomy as items or classes of items such as the classes of "Property, Plant and Equipment" which include "Land", "Building", etc. At other times classes of information are captured within a tuple. Concepts are expressed using both methods. Time will tell if the appropriate method was used for specific concepts within the taxonomy. Using item concepts maximizes comparability; using tuples hinders comparability to a degree (precisely what degree is yet to be determined). Adding "Codes" to tuples is an effort to decrease the amount of lost comparability when using a tuple.

Continued use of the USFRTF will prove that the taxonomy is what is desired, ensuring that what exists is correct, ensuring that pieces are not missing, and that relationships are correctly expressed. This step in the evolution of the UFRFTF has not yet occurred but is getting some traction as result of the XBRL programs in place at the Federal Deposit Insurance Corporation (FDIC) and Security & Exchange Commission (SEC).

The trick will be not only to heavily make use of the USFRTF but also to evolve it and correct any errors reported by the market. Key is that in the process it is important not to disrupt the financial markets which rely on the financial information being reported.

10.9. Understanding the Taxonomy Components In this section we will explain the USFRTF taxonomy components at a moderate level of detail so that users can better understand how to "move around" the taxonomy, how to read it, where to go for additional information, and generally how to make use of the taxonomy. We will also summarize useful information in this section important in better understanding taxonomy components.

A common mistake made by users time and time again is to believe that a reporting item that should exist in the taxonomy does not exist when in fact it does exist…it’s just the user can’t find it. It is very important to spend time to understand the different "areas" within the taxonomy so that looking for and finding specific items is simple and straightforward.

While you can open up the taxonomy files (the physical XML files) and see what is going on, you would have to have a good understanding of XML, XML Schema, and XBRL in order to really make sense of all the information. We are trying to avoid getting into the technical level, so we will focus on looking at reports and other user-friendly ways of exploring the taxonomy.

Using financial reports as the basis for exploring, it is possible to get a thorough understanding of the taxonomy. One does need to understand how to read GAAP-based financial reports. Keep in mind that the official version of the taxonomy is the information contained in the XML files themselves.

The USFRTF is quite large, and will grow even larger. It would not be practical to cover each part of every taxonomy included in the USFRTF in this document, as we are attempting to provide only an overview. So, we will continue to focus on



one industry taxonomy, the "Commercial and Industrial Companies" or CI taxonmy. The process we use for looking at this taxonomy can be used to look at the other component taxonomies of the USFRTF.

10.9.1. Understanding the Physical Files and their Relation This section describes the physical files of the CI taxonomy (us-gaap-ci namespace prefix). The starting point for the CI taxonomy is the following file:

http://www.xbrl.org/us/fr/gaap/ci/2005-02-28/us-gaap-ci-2005-02-28.xsd

If you obtain the file above and load it into an XBRL tool, the XBRL tool will locate all the other files which it needs to piece together the entire CI taxonomy. The following are all the files which would be obtained by the XBRL processor of the given tool:

us-gaap-ci Calculation linkbase

http://www.xbrl.org/us/fr/gaap/ci/2005-02-28/us-gaap-ci-2005-02-28-calculation.xml

us-gaap-ci Presentation linkbase

http://www.xbrl.org/us/fr/gaap/ci/2005-02-28/us-gaap-ci-2005-02-28-presentation.xml

usfr-ptr XSD http://www.xbrl.org/us/fr/common/ptr/2005-02-28/usfr-ptr-2005-02-28.xsd usfr-ptr Calculation http://www.xbrl.org/us/fr/common/ptr/2005-02-28/usfr-ptr-2005-02-28-calculation.xmlusfr-ptr Presentation http://www.xbrl.org/us/fr/common/ptr/2005-02-28/usfr-ptr-2005-02-28-

presentation.xml usfr-pte XSD http://www.xbrl.org/us/fr/common/pte/2005-02-28/usfr-pte-2005-02-28.xsd usfr-pte Labels http://www.xbrl.org/us/fr/common/pte/2005-02-28/usfr-pte-2005-02-28-label.xml usfr-pte Presentation http://www.xbrl.org/us/fr/common/pte/2005-02-28/usfr-pte-2005-02-28-

presentation.xml usfr-pte Reference http://www.xbrl.org/us/fr/common/pte/2005-02-28/usfr-pte-2005-02-28-reference.xml Reference parts (Not sure whether I should add this)

When considered as a whole, all of these files make up the CI taxonomy and allow XBRL tools to present the taxonomy in a way users can understand.

10.9.2. Reports of Taxonomy Information Available There are several different reports which come with the CI taxonomy that will help with better understanding its detail. All of these reports, which can be found at the CI link provided above, come in a variety of formats: PDF, Excel, and HTML. Although each format is beneficial, we will focus on the PDF versions of these reports. A URL for each of these reports will be provided to make it easy for you to locate the actual report.

Note that the official reports from the web site of the CI taxonomy are being used below. These may not be the best reports to use, as they are cluttered with too much information in many cases. If you have an XBRL tool, you can regenerate these reports to be more readable, or you can try and obtain alternative reports from other sources.

10.9.2.1. Element/Concept List Report The following is a screenshot of a portion of the report of elements/concepts in the CI taxonomy. This report can be found at the following URL:

http://xbrl.org/us/fr/gaap/ci/2005-02-28/Elements%20by%20Label%20%20CI_2005-02-28.pdf



This report contains a flat listing of every element/concept defined in the taxonomy and any taxonomies referenced by this taxonomy. Specific to the CI taxonomy, it does not define any concepts itself. Instead, references the usfr-pte which does define concepts.

Information provided for each concept on the report includes:

• "ID" or identifier. The ID is not actually part of XBRL but instead an automatically incremented number that helps make the concepts more readable/trackable. This is very useful when you want to refer to a particular concept and can easily reference "ID 5", for example.

• "Bal" or balance type, which will either be "D" for debit, "C" for credit or blank meaning there is no balance type assigned. This is an indication of what the “natural” balance for the item is; for example, assets are “naturally” debits so if the value is positive it should be read as a debit and if negative, a credit.

• "Per" or period type which will always be I for instant (as of date – e.g. for balance sheet items) or D for Duration (from/to dates – e.g. for P&L items).

• "Nil" or nillable attribute value; T means true (item can be left empty when creating instance documents), blank means false (item must have a value when creating instance documents).

• "Type" or data type – see “Concepts/Elements” section later for more detail on what these types are and their effect.

• "NS" or namespace prefix. Note that all the concepts have a namespace prefix of usfr-pte. If there were other taxonomies included then they could be identified by their different namespaces.

• "Labels/Name/Documentation", a list of the all labels, the XML unique name and human readable definition for the concept. For ID 5 above, you can see the element name and four labels of that element listed after the name. Further note that the label role (Terse label, for example) is included. Concepts can have a number of labels which can be used in different circumstances, these are distinguished by the “roles”. They can also be in different languages, but right now the CI taxonomy only has English available.

• "References" to authoritative guidance – see “References” section later for more detail.



If you go to the end of this report you’ll find ID number 1503, exactly the number of concepts defined in the taxonomy (one concept per ID). This point is important to remember as in the presentation and calculation reports, concepts may appear multiple times. But in the element/concept list, each concept appears only once.

One feature of the element/concept report is that although each concept is listed, the concepts are in alphabetical order instead of any kind of presentation or report order. This causes the concepts to be seen out of their typical context and thus may make understanding the meaning of individual concepts more difficult.

The presentation-oriented taxonomy reports give a better understanding of the taxonomy as it relates concepts in the way they tend to appear on financial reports. However, you need to be careful as the presentation report shows relations, not concepts. Relations can appear several times in presentation reports and yet point to or use the same concept. This is an important concept to keep in mind.

In summary, the element/concept listing is a good listing of concepts, but it does have limited use and utility.

10.9.2.2. Presentation Reports The presentation reports are the best reports for understanding taxonomies. Keep in mind that the presentation report shows relations, not concepts. As such, concepts can appear in multiple places on the presentation report and yet refer to the same concept.

The presentation report of the CI taxonomy can be found at this URL:

http://xbrl.org/us/fr/gaap/ci/2005-02-28/Presentation%20%20CI_2005-02-28.pdf

Again, this report is a bit cluttered as it is showing all the labels and documentation for each presentation “concept”, making it difficult to read the



report and use it for certain purposes. If the report were regenerated, say, to display only a single label, it would make the report easier to understand.

The CI presentation reports provide a summary of the presentation links in the CI taxonomy. It is similar to the element/concept report, but shows the appropriate labels (standard, beginning balance, ending balance, etc.) for each concept instead of the element name and all types of labels. Since the CI taxonomy has a unique label for each concept, you can look at the taxonomy quite effectively using just the label.

Another significant difference with this report is that it shows extended links. Each presentation link is contained within an extended link which "partitions" the presentation links into "sets" or "networks" as they are referred to within XBRL. Note that the concepts themselves in the concepts report discussed above are not partitioned by extended links, as only relations can be partitioned.

For example, ID 1 above shows the extended link with the label "Statement of Financial Position" or balance sheet. It is undesirable for, say, the direct cash flows statement and the indirect cash flows statement to be combined together; therefore, they are in different extended links which keep them partitioned. We will see more on this later.

While the element/concept report shows concepts only once, concepts may appear on the presentation reports a number of times. For example, the concept "Net Income" appears in the income statement, statement of equity, cash flows statement, and various places in the notes to the financials. The information about the concept (Reference, NS, Type, etc.) will be the same for each presenation concept occurrence. What could be (and most times will be) different is the "parent" the given concept is related to.

The relationship between a concept and another concept is shown by the indentation under the label. When there is an indentation that means there is a “parent-child” relationship between the outer concept and the indented concept – i.e. all the indented concepts “belong to” the outer concept. When there is no indentation, concepts are called “siblings” – i.e. they “belong together” or can be thought of as existing at the same level.

An important topic to discuss related to how concepts are presented is abstract elements. In the CI presentation report above, ID 3, "Assets", is an abstract element. Abstract elements are included purely for organizing the taxonomy itself and have no effect on, nor appear in, any resulting financial report. They are like “placeholders” or “headings”. The presentation report identifies an abstract element by the Type having parenthesis (for example "(String)") and the label is in italics.

Every concept used by the CI taxonomy is shown on the presentation reports. Concepts not shown are not intended to be used by the CI taxonomy.

10.9.2.3. Calculation Reports A third way to look at a taxonomy is using the calculation report which, for the CI taxonomy, can be found at the following URL:

http://xbrl.org/us/fr/gaap/ci/2005-02-28/Calculation%20%20CI_2005-02-28.pdf



Note that each "bar" (white or gray) is one taxonomy concept, similar to the display on the element/concept and presentation reports. Both the label and the concept name are shown on the report; removing the concept name from this report would make it clearer.

The calculation report shows calculation relationships between concepts. The report is very similar to the presentation report, but there are some differences.

The "Wgt" or weight column shows the XBRL "weight" attribute value for the calculation relationship. For example, ID 6, "Cash – Unrestricted" has a "Wgt" value of 1. "Cash – Unrestricted" is indented under "Cash and Cash Equivalents" (ID 5), its parent.

A weight of “1” means that the given concept adds into its parent while a weight of “-1” indicates it subtracts from its parent. For example, we might have a parent “Fixed Assets, Net” that has 2 children – “Fixed Assets, Gross” and “Accumulated Depreciation, Fixed Assets”. “Fixed Assets, Gross” would have a weight of 1 and “Accumulated Depreciation, Fixed Assets” would have a weight of -1 so that “Fixed Assets, Net” can be calculated as “Fixed Assets, Total” minus “Accumulated Depreciation, Fixed Assets”.

Addition and subtraction (1 or -1) are the only mathematical operations you can do within the Calculations links. A more sophisticated mechanism, the formula linkbase, is being developed by XBRL International to overcome this limitation.

Only elements which are involved in calculations are shown on the calculations report. There are extended links shown on the reports for calculations and those extended links can be different to the presentation links, although their purpose is exactly the same. And again, this report shows links, not concepts. A concept can have more than one calculation link, therefore it can appear on this report in multiple places. Usually if a concept appears on this report more than once, it will be within different extended links.

10.9.2.4. Definitions Report The USFRTF presently has no definition links, and as such, there are no definition reports included with the taxonomy.

10.9.2.5. Explanatory Notes or Taxonomy Documentation The explanatory notes or taxonomy documentation can be found at the following URL:

http://www.xbrl.org/us/fr/gaap/ci/2005-02-28/us-gaap-ci-2005-02-28.htm

This documentation contains additional information about the CI taxonomy which is not contained in the XML Schema or linkbase files. This includes legal information, terms and conditions of use, disclaimers and other information of a legal nature which might be deemed important.



10.9.2.6. Sample Instance Documents The CI taxonomy, like other taxonomies in the USFRTF, provides a number of sample instance documents which help users understand the taxonomy. These can be found at the following URLs:

http://www.xbrl.org/us/fr/IDs/Bowne%20and%20Co.,%20Inc.zip

http://www.xbrl.org/us/fr/IDs/Microsoft.zip

http://www.xbrl.org/us/fr/IDs/XII.zip

These sample instance documents can be very helpful in understanding the taxonomy. There may or many not be style sheets or other functionality to render the information in the instance documents.

At some point more of a user's guide or a financial reporting instance document creation guide may become available. This guide might explain in more detail how to create instance documents. But for now, these samples are the best examples to show what an instance document created with the CI taxonomy might look like.

10.9.3. Extended Links Defined by CI Taxonomy The CI taxonomy defines the following extended links which are summarized in the table below. These extended link roles are physically defined, per the XBRL specification, in the file: us-gaap-ci-2005-02-28.xsd. In addition, other extended links are defined by the primary terms relationships taxonomy in the file usfr-ptr-2005-02-28.xsd, which is imported by the CI taxonomy, therefore they are used by the CI taxonomy.

Provided in the table below are the URI of the extended links and the human readable definition for that link. All extended links are defined so they can be used on either the presentation or calculation linkbases, but not the definition linkbase. If you wish to create an extension taxonomy and use these links; then you would have to define them and allow them to be used on the definition linkbase.

The following are defined by the CI taxonomy:

Extended Link URI Extended Link Definition http://www.xbrl.org/us/fr/lr/role/IncomeStatement Income Statement

http://www.xbrl.org/us/fr/lr/role/StatementFinancialPosition Statement of Financial Position

http://www.xbrl.org/us/fr/lr/role/CashFlowOperationsIndirect Cash Flow from Operations - Indirect Method

http://www.xbrl.org/us/fr/lr/role/StatementCashFlows Statement of Cash Flows

http://www.xbrl.org/us/fr/lr/role/CashFlowOperationsDirect Cash Flow from Operations - Direct Method

The following are defined by the Primary Terms Relations taxonomy:

Extended Link URI Extended Link Definition

http://www.xbrl.org/us/fr/lr/role/TupleContentModelsCommonTerms Tuple Content Models - Common Terms

http://www.xbrl.org/us/fr/lr/role/Notes Notes to the Financial Statements

http://www.xbrl.org/us/fr/lr/role/AlternateCalculationRollUps1 Alternate Calculation Roll-ups

http://www.xbrl.org/us/fr/lr/role/StatementStockholdersEquity Statement of Stockholders' Equity

http://www.xbrl.org/us/fr/lr/role/TotalStockholdersEquityCalculation Total Stockholders' Equity Calculation

Note that the extended link definitions are unique, which is not required, but very helpful so we can use the more human-friendly definitions rather the rather funky URIs to refer to the extended links. Having unique extended link role definitions allows software vendors to hide the URI and use the definition.



Throughout this document we will use the more human-friendly Extended Link Definitions, rather than the more official URI, as they are easier to understand.

Also, within XBRL there is no way to order extended links, they sometimes appear in rather random order with XBRL software tools. Other tools order the extended links in the order they appear within a linkbase. While this is helpful, it is not a part of the XBRL standard and it cannot be relied upon to provide a consistent presentation order of extended links. Eventually, it is likely that the ability to order extended links will be available within XBRL. For our purposes, we will order these extended links in an order which is understandable to accountants, as they are the target for this document.

10.9.4. Concepts/Elements As mentioned earlier, there are 3,066 elements/concepts defined in the PTE (Primary Terms Elements) taxonomy. The CI taxonomy actually defines no additional concepts. The following summary information relates to all the concepts used within the CI taxonomy. This is intended to explain pieces of XBRL to non-technical users of the taxonomy.

Attribute Explanation name Each concept in the taxonomy has a name. The name value is

automatically created from the standard English label for the concept. For example, the label "Property, Plant and Equipment, Net" would have the name attribute of "PropertyPlantAndEquipmentNet". This naming pattern is followed throughout the taxonomy. The naming convention follows FRTA rules. No words are dropped, only characters are dropped such as "," and "(". It should be noted that the name has no inherent meaning, it is only a unique identifier for each concept in the taxonomy.

id Each concept has a unique id attribute as required by FRTA. Also, each id attribute value is a concatenation of the concept's name and the namespace prefix of "usfr-pte" with an underscore. For example, the concept named "PropertyPlantAndEquipmentNet" would have an id attribute value of "usfr-pte_PropertyPlantAndEquipmentNet". This is not to be confused with the “ID” number that is shown on the reports.

type The type is basically the data type of the concept. Data types used in the USFRTF and shown on the reports include: Monetary (xbrli:monetaryItemType) – which is basically a decimal

number which must have a unit of measure associated with it of one of the ISO currency codes.

String (xbrli:stringItemType) – which is basically textual type information.

Token (xbrli:tokenItemType) – which is textual type which is more restrictive than stringItemType. Only single spaces are allowed, no leading or trailing spaces.

Shares (xbrli:sharesItemType) – which is basically a decimal numeric value indicating the number of shares.

Decimal (xbrli:decimalItemType) – a decimal number. Date (xbrli:dateItemType) – which is a date expressed as yyyy-

mm-dd. Date/Time (xbrli:dateTimeItemType) – which is a date plus additional

time information expressed as yyyy-mm-ddThh:mm:ss. Year (xbrli:gYearItemType) – which is a date, but only the year

portion is used and is expressed as yyyy. Boolean (xbrli:booleanItemType) – which is a true or false value. A special word about tuples. Tuples don’t have types. Tuples are basically complex structures or information which must be used together as a group to be properly understood. Tuples will be explained later.



Attribute Explanation One custom types are defined and are discussed in the next section.

Nillable Each concept has a nillable attribute with a value of "true", as required by FRTA. This allows the use of the "nil" attribute within instance documents.

periodType Each concept, as required by the XBRL specification has an "instant" (as at date) or "duration" (from/to dates) periodType attribute value.

balance Each concept, where appropriate, has a balance attribute value of "debit" or "credit" if applicable. If a balance attribute value is not applicable, then there is no balance attribute.

substitutionGroup Each concept, as required by the XBRL specification, has a substitutionGroup attribute value of "item" or "tuple", as appropriate.

10.9.5. Custom Types Defined (Data Types) The USFRTF defined the following custom types in the following physical file: usfr-ime-2005-06-28.xsd. No custom types are defined in the CI taxonomy. However, there probably should be or will be when the notes are built out into more detail. Showing these other USFRTF custom types helps point out the value of custom types and explains what they are.

Name Based on Type Explanation usfr-ime:PutCallItemType xbrli:tokenItemType The value is restricted to one of the

following values: Put Call

usfr-ime:LongShortItemType xbrli:tokenItemType The value is restricted to one of the following values: Long Position Short Position

usfr-ime:AffiliatedUnaffiliatedItemType

xbrli:tokenItemType The value is restricted to one of the following values: Affiliated Unaffiliated

Custom types, which are basically data types, used by the USFRTF basically all taxonomy creators to impose tighter restrictions on data to be put into an XBRL instance document values beyond what base types allow. For example, xbrli:stringItemType can be any string; however, usfr-ime:PutCallItemType requires the value to be not just a string, but one of the specific strings "Put" or "Call". This improves data quality within instance documents.

Currently, these custom types are defined in individual taxonomies, such as the investment management taxonomy which defines the types shown above. In the future, it is highly likely that all these custom types will be defined in on location (one physical file) and then used by the entire USFRTF. It may even be the case that XBRL itself defines additional types, FRTA may define types or types are shared between the USFRTF and the IFRS framework. Doing so would increase comparability and reduce errors in instance documents.

10.9.6. Current Thinking Regarding Presentation and Calculation Links

The CI taxonomy has presentation links which are all physically located in three files; those provided by the Primary Terms Relations taxonomy (usfr-ptr-2005-02-28-presentation.xml), those defined by the Primary Terms Elements taxonomy



(usfr-pte-2005-02-28-presentation.xml) and those defined by the CI taxonomy (us-gaap-ci-2005-02-28-presentation.xml).

An XBRL processor takes all these physical files, puts them together, and then puts extended links together by extended link role to create "networks" of relations which can be used by the XBRL processor.

How to best organize these linkbases has always been a question to taxonomy creators, and an answer is appearing. The trend seems to be at the current time, and the USFRTF creators have expressed a desire, to move more toward how the IFRS-GP taxonomy has structured its presentation and calculation links. What the IFRS-GP taxonomy did was to basically segregate presentation and calculation links by statement. For example, there is a separate physical file for the "Statement of Cash Flow – Direct method" and a different physical file for "Statement of Cash Flows – Indirect method". The reasoning is that entity reporting using XBRL would never use both methods, direct and indirect; they would pick one or the other. If they are in separate files, the creator of the instance document can pick the one they desire and use that for their cash flows statement, and then don’t have the extra undesired cash flow statement information. Currently in the USFRTF, taxonomies typically put all the extended links into one physical file, so they cannot be separated. Another option might be for XBRL international to create some means of prohibiting an entire extended link.

Additionally, the IFRS-GP taxonomy did not go far enough in partitioning financial statement components. Whereas each statement is in separate files, the notes, which make up over 50 percent of the taxonomy, are in one file. It is highly likely that the IFRS-GP taxonomy and others will further break down the notes into separate extended link, possibly by disclosure. Perhaps the policies and disclosures will be combined into one set for each disclosure; for example "Intangible Assets Policies" and "Intangible Assets Disclosures" into one physical file.

Also, it may be the case that both presentation and calculation linkbases for the same financial statement component will be put into the same physical file. This is not currently allowed by FRTA; but it make sense that the "Balance Sheet presentation and calculation would always be used together, so it seems as though they belong in the same physical file.

Also, as mentioned earlier, there is no way to order extended links. This feature will likely be added to XBRL at some point.

Another issue separating extended links into separate files solves relates to calculations. When you have, say, both the direct and indirect cash flows statement calculations in one physical file, an XBRL processor must try and calculation both because, again, there is no way to turn one of the statements off. As such, one of the statements will calculate incorrectly as facts provided in the instance document only exist for one of the cash flow methods. But as some of the concepts are shared by both methods, both networks of calculations are "fired" by the XBRL processor. Putting the direct and indirect calculations into separate physical files makes it so instance creators can use the calculations they desire, not use the undesired set, and there are no calculation inconsistencies. This is another argument for a larger number of smaller sets of presentation and calculation linkbases.



10.9.7. Presentation Links As was mentioned above, the CI taxonomy has three physical presentation linkbase files. These files contain extended links which are put together by an XBRL processor.

The presentation linkbases and presentation reports are the most human-friendly of the linkbases in taxonomies. Every effort was made to organize the presentation linkbases so an accountant or analyst (preparer or consumer) would be comfortable with navigating the taxonomy. The presentation linkbases are not intended to be used for rendering financial statements; however, rendering information can be gleaned from the presentation linkbase.

The following is a summary of extended used within the CI taxonomy organized in a manner logical to an accountant or analyst. The order of these extended links may be different on reports you view or in different taxonomy tools; but this is basically what you have:

Extended Link Definition Explanation Statement of Financial Position The Statement of Financial Position extended

link "network" contains concepts which make up what is commonly called a "Balance Sheet" (573 out of 600 statements per the AICPA's Accounting Trends and Techniques). This balance sheet is a classified formant, showing breakdowns of current and non-current assets and liabilities.

Income Statement The Income Statement extended link contains concepts which make up an income statement. The format of the income statement is multi-step (as opposed to single-step).

Statement of Cash Flows The Statement of Cash Flows extended link contains concepts which make up the investing activities, financing activities, exchange rate gain, reconciliation between the beginning and ending balance of cash, and supplemental information. The concept "Net Cash Flows Provided By/(Used In) Operating Activities" is contained in this network, however the details used to compute it are not. The reason for this is that there are two ways of calculation this number: direct method and indirect method. Each of these sets of details are provided in separate sets of concepts.

Cash Flow from Operations - Indirect Method

This extended link network contains concepts to use the indirect method of calculating net cash flows from operating activities.

Cash Flow from Operations - Direct Method

This extended link network contains concepts to use the direct method of calculating net cash flows from operating activities.

Statement of Stockholders' Equity The Statement of Stockholders' Equity extended link contains links for concepts which make up the statement of equity. Basically, increases and decreases in the components of stockholders equity is reconciled here.

Total Stockholders' Equity Calculation

Notes to the Financial Statements This extended link contains the accounting policies and explanatory disclosures which would be in a set of financial statements. This extended link contains the most concepts.

Alternate Calculation Roll-ups



Extended Link Definition Explanation Tuple Content Models - Common Terms

This extended link contains tuples, or complex concepts. FRTA requires that tuples have presentation links which show the users of the taxonomy the contents of each tuple. This extended link has this information. The actual tuples are defined in the XSD (schema) file, not the presentation linkbase. Be sure to read the section of this document which discusses tuples.

Every effort was made to make the presentation and calculation linkbases as similar or consistent as possible, in order to make it easier for humans to use the linkbases.

10.9.8. Calculation Links One approach to creating calculations is to separate extended links are "self contained". Another way is to express calculations only once and then let a human piece the calculations together. This means that certain calculations are expressed two or more times, which causes additional maintenance and increases the possibility of errors; however, given the state of XBRL processors and their inability to show calculations across extended links the taxonomy accepts the additional maintenance burden and the burden of ensuring the consistency of these calculations at this point. This may change with future versions of the taxonomy.

The USFRTF tries to express calculations only once. This can be seen in the way that the statement of cash flow is constructed. Note that the net operating activities are separated into two extended links for the direct method and the indirect method. An alternative would be to have two totally separate statements.

The point is that one method makes things easier for the users; the other makes it easier for the taxonomy creators to maintain and build the taxonomy. There is no real right answer; only preferences of one approach or the other.

Note that below, only differences between the calculation linkbase and presentation linkbase are highlighted. Remember that not all concepts in a presentation linkbase will show up in a calculation linkbase. Only calculation relationships are shown. No abstract elements, no strings, no tuples, and concepts not involved in calculations appear in a calculation linkbase. Or another way of saying this is that only numeric concepts may appear in calculations.

Extended Link Definition Explanation Statement of Financial Position Same as presentation linkbase. Income Statement Same as presentation linkbase. Statement of Cash Flows Same as presentation linkbase, except that the

reconciliation between beginning and ending cash is not shown as that type of calculation cannot be performed by XBRL calculation linkbases.

Cash Flow from Operations - Indirect Method

Same as presentation linkbase.

Cash Flow from Operations - Direct Method

Same as presentation linkbase.

Statement of Stockholders' Equity Same as presentation linkbase.



Extended Link Definition Explanation Total Stockholders' Equity Calculation

This extended link calculations the "other perspective" of the statement of equity. The statement of equity both "foots" (top to bottom) and crosscasts (side to side). These relations cannot be expressed in the same extended link as they would conflict. As such, this perspective contains one of these relationships.

Notes to the Financial Statements Same as presentation linkbase. Alternate Calculation Roll-ups Again, where calculations would conflict,

alternative calculations are placed in this extended link. This extended link contains only one alternative calculation from the area of the notes to the financial statements.

Tuple Content Models - Common Terms

This extended link contains tuples, or complex concepts. FRTA requires that tuples have presentation links which show the users of the taxonomy the contents of each tuple. This extended link has this information. The actual tuples are defined in the XSD (schema) file, not the presentation linkbase. Be sure to read the section of this document which discusses tuples.

Also note that certain types of calculations are not currently supported by XBRL. The primary type of calculation which is not expressed in the calculation linkbase of the CI taxonomy is the "movement analysis" type of calculation. The movement analysis has this type of calculation: Beginning Balance + Changes = Ending Balance.

XBRL calculation linkbases do not support cross-context calculations, and the beginning balance, the changes, and the ending balance would be in different contexts. This is because the beginning balance is “as of” one date, while the ending balance is “as of” another date. Different dates require different contexts in XBRL. The changes are a duration type of period (from/to) and thus also require a different context when reported. Therefore, you will not find reconciliation-type calculations expressed in the calculation linkbase.

As mentioned earlier, a more sophisticated mechanism, the formula linkbase, is being developed by XBRL International to overcome this and other limitations. There are some proprietary solutions to this available now if you can’t wait for the open version. It is hoped/expected that these proprietary solutions will migrate to the open version when it’s released.

10.9.9. Definition Links No definition links are provided with the current version of the CI taxonomy (or for other taxonomies which make up the USFRTF). It is recognized that definition links hold a tremendous amount of power; however limited resources and a necessary focus on the core taxonomy precluded the team creating the CI taxonomy from adding definition links at this time.

Definition links can be used to provide additional information about the taxonomy which can then be useful to a computer. It may look like a computer would have a good understanding of the taxonomy, but this is not the case. Humans tend to project their ability to differentiate between concepts in the taxonomy onto what computers can do.

For example, there is no way to provide a list of all the, say, policies in the taxonomy, other than to search for the word "policy" and hope the taxonomy was created consistently and has the word "policy" for each accounting policy. Rather



than using this implicit mechanism for identifying policies, a definition link can be created to identify every policy in the taxonomy. This is only an example of one feature the definition linkbase provides.

Other mechanisms can be used to express a rich set of information, expanding on information contained in the actual taxonomy. Some of these definition links could be publicly available, others would remain proprietary.

It is likely that proprietary definition linkbases will be created for the CI taxonomy and the USFRTF in general and it is expected that future versions of the taxonomy will contain definition links.

10.9.10. Labels The CI taxonomy (and the USFRTF in general) contains one label linkbase for each taxonomy which expresses labels for the taxonomy in English. It is highly likely that other languages will become available, for example a Japanese set of labels was discussed.

Every CI taxonomy (and the USFRTF in general) concept has a unique label; no two labels are the same in the label linkbase for the standard label role. As such, USFRTF concepts can safely be referred to by their standard label and be guaranteed unique in applications (as opposed to having to work with element names to be sure you are using the correct concept.

"Standard" label roles are provide for all taxonomy concepts, and beginning balance ("Period Start Label"), ending balance ("Period End Label"), and a terse label are provided where appropriate.

Additionally, documentation for the taxonomy exists for many concepts using "documentation" label roles. The documentation is an unofficial (not part of the house of GAAP). It is highly likely that others will create document for the USFRTF; probably many different sets. For example, perhaps Wiley and Millers, both of which provide GAAP Guides, could provide through, comprehensive documentation for the entire USFRTF. Or perhaps somewhat of a "wiki" created by educators in the form of USFRTF documentation may be created.

Further, it is highly probably the reporting entities will provide their own labels for concepts used in instance documents.

The following is a summary of the label roles use in the USFRTF:

Extended Link Definition Description Count of Usagehttp://www.xbrl.org/2003/role/label Standard 3,447 http://www.xbrl.org/2003/role/terseLabel Terse 3,141 http://www.xbrl.org/2003/role/documentation Documentation 3,248 http://www.xbrl.org/2003/role/periodStartLabel Beginning of Period 178 http://www.xbrl.org/2003/role/periodEndLabel End of Period 24 http://www.xbrl.org/2003/role/negativeLabel Negative Value 6 http://www.xbrl.org/2003/role/positiveLabel Positive Value 6 http://www.xbrl.org/2003/role/totalLabel Total in Calculation 344

10.9.11. References The CI taxonomy contains one reference linkbase through the import of the Primary terms elements taxonomy. References do not exist for all concepts.

The reference parts used, as required by FRTA, are the standard reference parts defined by the namespace "http://www.xbrl.org/2004/ref" in the following file:

http://www.xbrl.org/2004/ref-2004-08-10.xsd



These reference parts consist of:

Reference part name Explanation Publisher Publisher of the reference material, such as SEC, FASB, or AICPA. Name Name refers to the specific publication. For example, "Statement of

Financial Standards", "Statement of Position" or "IFRS". It does not include the number.

Number Number is used to record the actual number of the specific publication. For example, the number for FAS 133 would be 133.

IssueDate The issue date of the specific reference. The format is CCYY-MM-DD. Chapter For a publication that uses chapters, this part should be used to

capture this information. Because chapters are not necessarily numbers, this is a string.

Article Article refers to a statutory article in legal material. Note Notes can contain reference material; use this element when the

note is published as a standalone document. There is a separate element for footnotes within other references.

Section Section is used to capture information typically captured in sections of legislation or reference documents.

Subsection Subsection is a subsection of the section part. Paragraph Paragraph is used to refer to specific paragraphs in a document. Subparagraph Subparagraph of a paragraph. Clause Sub component of a sub paragraph. Subclause Subcomponent of a clause in a paragraph. Appendix Refers to the name of an Appendix, which could be a number or text. Example Example captures examples used in reference documentation; there

is a separate element for Exhibits. Page Page number of the reference material. Exhibit Exhibit refers to exhibits in reference documentation; examples have

a separate element. Footnote Footnote is used to reference footnotes that appear in reference

information. Sentence In some reference material individual sentences can be referred to,

and this element allows them to be referenced. URI Full URI of the reference such as "http://www.fasb.org/fas133". URIDate Date that the URI was valid, in CCYY-MM-DD format.

Theoretically, all reference material in the set of all pronouncements which make up US GAAP are covered by these reference parts. If there is a part which is missing, the reference parts schema can be extended by adding a new reference part. However, if one of the above parts fit, it should be used.

Eventually two things will most likely occur to reference materials. First, they will be provided in an XML format, preferably a standard format (probably NOT XBRL) and be made available over the Internet for free or for a fee. Second, the reference materials will be cross-referenced to the USFRTF concepts so users can move from the USFRTF to the references (because they are available over the internet in an XML format) and from the pronouncements to the USFRTF (as concepts in the framework are referenced in the pronouncements). This will make life significantly easier for users. In addition to pronouncements being provided, other resources such as Wiley and Miller GAAP Guides may work in this manner one day.

Another important point to understand about references is the concept of the reference role. And, although the USFRTF does not currently make use of this feature, it is highly likely that it will eventually.

The accounting pronouncements provide lots of different types of information: presentation information, measurement information, disclosure information,



definitions of concepts, commentary, examples, samples, etc. References can be distinguished by what information it provides using this role. These roles are defined in the XBRL specification and further explained in the FRTA.

10.9.12. Formulas The XBRL International formulas linkbase specification is not complete and therefore formulas were not created for the USFRTF. However, proprietary formulas solutions exist and can be used to express relationships, such as reconciliation-type relations, which cannot be expressed using the XBRL 2.1 calculation linkbase.

It is likely that the formulas specification will be released, perhaps, sometime between March and June 2006.

10.9.13. Modularity As mentioned, the USFRTF is a collection of about 53 separate physical files. While, theoretically, the entire USFRTF could exist in one physical file, for purposes of maintenance of the taxonomies, usability of the taxonomies, etc, the taxonomies are broken down into separate files.

Current thinking in terms of modularity point to the following future direction for the USFRTF:

• It is highly likely that the presentation and calculation linkbases will be separated more than they are currently. Presently, most individual taxonomies (such as the CI, PTE, PTR) have one file which contains all presentation extended links and another file containing all calculation extended links. It is highly likely that presentation linkbases components will be more segregated in the future having creating more physical files.

• It might be the case, although doubtful, that the taxonomy could be broken out by accounting standard. For example, their could be a separate taxonomy for FAS 133.

• It is perhaps likely that the taxonomies split files apart by disclosure category; for example creating a taxonomy for "Property, Plant and Equipment" disclosures, and a different taxonomy for "Employee Benefits" disclosures. Or, it might be that both accounting policies and disclosures could be put into one taxonomy for a disclosure category.

• It may be the case that presentation and calculations could be combined as they are always used together for a specific section of the taxonomy, say the Balance Sheet.

• Some other undiscovered option.

The point is that the taxonomy can exist in many states and through use of the taxonomy, the proper state will be discovered and the taxonomy will evolve to that state. There is a balance between a large number of separate files which may be easy to maintain, but harder for users to use because of the sheer volume of the number of files. But on the other hand, a small number of files which may (or may not) make things easier for users would make maintaining the taxonomy much more difficult.

10.9.14. Future Taxonomy Release Strategy/Policy Currently, XBRL-US, who owns and is responsible for maintaining the taxonomy, has not indicated a specific taxonomy release strategy, policy, or schedule. The general idea for release however is to release taxonomies each year as needed,



probably sometime in June/July, as is the case for most accounting pronouncements. This gives the users time to obtain and understand the pronouncements prior to having to make use of them.

But the following are some considerations relating to taxonomy release strategy:

• Some sort of taxonomy release strategy will probably be communicated and used consistently. This make it so software developers, creators of financial statements, analysis can predict what they will have to be using.

• There will likely be some sort of version control between versions of the taxonomy. For example, some indication of what was changed between the 2005 and 2006 versions of the taxonomy would be quite useful to users.

• Some mechanism for dealing with errors in the taxonomy will need to be in place. For example, particularly in the early years of the taxonomy, errors will undoubtedly be uncovered. How will those errors be fixed? Release an extension taxonomy? Allow or force users to create their own extension taxonomies to correct the error which may lead to comparability issues? Change the released version of the taxonomy which could potentially be confusing to users and software developers? There are many options.

• Changes to accounting pronouncements need to be considered and how those will be (of if they should be) incorporated into the taxonomy.

Again, the information above is speculation. Use of the USFRTF will provide significant input into how to release future versions of the USFRTF.

10.9.15. Versioning of Taxonomies As previously mentioned, the XBRL International consortium intends to provide a versioning specification; however, that specification does not currently exist. Significant pressure is being exerted by potential taxonomy users to provide a path, or versioning, between taxonomy versions.

It is highly likely that some path will be provided between taxonomy versions. Perhaps through the use of extension taxonomies, proprietary versioning solutions, simple Excel spreadsheets or some other mechanism for tracking changes from one taxonomy to the next.

A method of versioning taxonomies is not expected from XBRL International until the end of 2006 at the very earliest.

10.10. Reading the Taxonomy The best way to eat an elephant is a piece at a time. In this section we take the elephant (the entire USFRTF) and break it into pieces and point out similarities and techniques to help you understand how to "read" the taxonomy.

On a side note, one of the better ways to truly understand the taxonomy is to create instance documents. One step removed from that is perhaps not creating them, but looking at instance documents that others have created. However one particular advantage of creating your own instance document is that it will contain data with which the “creator” is already familiar.

In a future section we will go over common patterns. Instance documents and taxonomies are provided to look at or even reverse engineer.



Fundamentally though, trying to understand XBRL taxonomies and instance documents is like anything else: the more you put into it, the more you get out of it.

10.10.1. Overview of Approach In the next sections, what we will do is start with small pieces of the USFRTF, starting with the CI taxonomy, explain the pieces, point out how these pieces relate to other pieces (patterns), and then build bigger and bigger pieces until you have the ability to "read" the CI taxonomy. Then you can apply those techniques to reating other areas of the USFRTF that you need to understand. What that means is that you will be able to look at a printout or some other representation of the taxonomy or instance document and you will know what is going on.

First, we will explain the strategy for organizing the taxonomy used by the creators of the taxonomy. Next, we will explain how to read single line items. After that we will explain how to read the relations between the line items. Then we will discuss specific "funky stuff" contained in the taxonomy which is more challenging to understand without a detailed explanation.

10.10.2. Approach to Structuring Taxonomy The best view of the taxonomy can be obtained from looking at the presentation linkbase. The reason is twofold. Firstly, it contains all the concepts which are used by the taxonomy. Secondly, the presentation extended links are in an order which is somewhat logically familiar to an accountant. The approach is as follows: we start with the Balance Sheets, then move on to Income Statements, followed by the Cash Flow Statements, Statement of Equity, Notes, and then all the other "stuff" which does not fit into one of those categories.

The flow within each extended link should be familiar to accountants. In general, things are in somewhat "balance sheet" and "income statement" order, similar to a set of audit working papers. This general strategy is followed throughout the taxonomy. Think of a balance sheet and income statement and think of audit working papers, consider that a loose guide, but look for the "nooks and crannies" where information exists, get the big picture, then try and understand the detailed concepts within that ordering.

Doing this can be a little tricky as there is no real order to extended links within a linkbase. This is overcome by some tools by using the physical order within the linkbase as the proper order for the extended links to be displayed in XBRL tools. However, this is not a part of the standard and not all tools use this approach.

10.10.3. Understanding One Line (Items) The following is a screenshot of one line, or item, from the CI taxonomy of the USFRTF:

The item shown above is taken from the presentation report. But, the reality is that it really makes no difference what report the line is on, or the item is from, because in isolation, there are no relations. The presentation and calculation linkbases need at least two parties; one on the "from" side and the other on the "to" side.

This is simply an item.



The following gives an explanation about how to look at a single item from the presentation report:

Component Value Explanation ID 8 The ID is simply an easy way to refer to lines on a

report. And has nothing to do with XBRL

Bal D The balance is "D" for debit. Per I The periodType is "I" for instant, or as at rather

than period. Nil T The concept is nillable. This means "nil" can be

used for this concept in instance documents or an "empty" value, sometimes meaning the value is unknown, can be provided.

Type Monetary The type of the concept is xbrli:monetaryItemType. Note that the application uses easier to read labels. Also note that you know that the concept is an item (rather than a tuple) because it were a tuple, the type would say "Tuple", you would not have a balance or period type, as tuples don’t have those. Tuples will be explained later; for now, we are dealing with items.

NS usft-pte The namespace prefix is usfr-pte; this is where the concept comes from.

Label Cash Equivalents

The label of the concept is "Cash Equivalents"; the name is most likely "CashEquivalents ".

References There are no references for Cash and Equivalents.

Pretty simple, that is all there is to it. There are 1,590 of these in the taxonomy and the same idea applies to each.

10.10.4. Understanding Relations Between Report Lines In the CI taxonomy there are two types of relations: presentation and calculation. Definition links are not provided so there are no definition relations. Below we will provide a brief tutorial, using the CI taxonomy from the USFRTF, to explain many of the common types of relationships between taxonomy concepts. For a more complete indoctrination of these relationships, readers may want to consider obtaining a copy of "The Patterns Document".

10.10.4.1. Presentation of Items Consider the presentation report below:

Lets focus on the lines with ID 6 through 9 for a moment.

The line ID 7, with the concept label "Cash - Unrestricted” is related to the element at line ID 6, "Cash and Cash Equivelents". ID 7 is a child of the element in line ID 6; notice the indentation. ID 7 is also related to ID 8, "Cash Equivalents". ID 7 and ID 8 are siblings; notice that the indentation level is the same. They both have the same parent which is ID 6.



Notice the word total in line ID 9, "Cash and Cash Equivalents - Total". It is below the things which add up. It is also the last line under the concept ID 6. What we are getting at will make a bit more sense when we discuss calculations, which we will do now.

Another thing to notice about the concept ID 6 "Cash and Cash Equivalents" is that this concept is abstract. You know that because on this report as it is bold italic, and the type has parenthesis, "(String)" as opposed to "String". The reason ID 6 exists in the taxonomy is to have a place to hook all the Cash and Cash Equivalents and in particular the last concept in the list, the total, ID 9 "Cash and Cash Equivalents - Total". Keep the location in your mind and contrast it to where this is in the calculation printout below.

10.10.4.2. Calculation of Items Below is a fragment of a calculation printout.

Notice ID 1 has the label Extended Link, just like the presentation report. But also notice two other things. First, there are no abstract elements or bold italic type as we had for ID 2, 3, 4, 5 and 6 in the presentation printout. Second, notice that the total, ID 5 is ABOVE the concept ID 6 "Cash - Unrestricted".

Lastly, notice that the labels are different for ID 9 in the presentation printout, "Cash and Equivalents – Total", and ID 5 in the calculation printout, "Cash and Equivalents". This label is different as the presentation report uses a preferred label role of "Total".

The reason the calculation is above is simply because that is how this computer application rendered this relationship. There is nothing in XBRL that dictates this, it is simply a common way to express a relationship, as a tree.

The element ID 6 "Cash - Unrestricted" is related to ID 5 "Cash and Cash Equivalents" in that the child element (ID 6) contributes to the concept ID 5 in a calculation.

Notice the "Wgt" (short for weight) column on the left; see the value of "1", this means that ID 6 is added to ID 5.

The same is true for the concept with the ID 7 "Cash Equivalents".

The “Wgt” column is worth exploring a little further. In this example intuition tells you that we need to add up all the children of ID 5. If we were looking at Trade Receivables and we wanted to reflect the bad debt provision as a concept, then the bad debt provision would have a weight of -1 so as the total would be the net of the gross figure and the allowance.

Eventually software applications will render these in a more intuitive way for accountants. But for now, this is pretty much how most XBRL tools render these relations, as inverted trees with the roots, or totals at the top.



So, hopefully you see the difference between the calculation and presentation printouts. The same approach can be applied to all the concepts in a taxonomy, except for tuples, which we will discuss in a moment.

10.10.5. Quick Summary of Understanding Items So, hopefully what you have seen relating to items above is as follows:

• You can see and understand the meaning of the attributes related to each line.

• You can tell the difference between an abstract concept and a non-abstract concept.

• You can see the different location totals show up in the presentation linkbase (on the bottom, which is intuitive) or in the calculation linkbase (on the top, which is not quite as intuitive).

If you understand the above, then you can probably read about 60 to 80% of the CI taxonomy and the USFRTF.

10.10.6. Multiple Levels of Disclosure The CI taxonomy and the USFRTF was built to easily accommodate different levels of disclosure. Part of the reason for this was to help make it possible for users of the taxonomy to ease into using XBRL, providing less marked up detail when they first adopt, but increasing levels of detail as software becomes more mature. This is not about the level of what is disclosed, but rather the level that a disclosure is marked up in XBRL.

Below is an example of providing different levels of disclosure:

Note the line above with ID 979, "Risks and Uncertainties Note". That concept is a string. The concept below that is ID 980 which is one portion of the "Risks and Uncertainties", the "Concentration of Credit Risk Note" part. Bellow that three types of credit risk are broken down in ID 981, 982, and983. A user could report at any of these levels, as each of these is a string.

These different levels of disclosure exist throughout the taxonomy.



If the taxonomy had made ID 979 an abstract concept, it would only be there to organize the taxonomy, but could not be reported; the details would need to be reported.

10.10.7. Understanding Tuples Tuples are basically "complex structures" or information which must be used as a group to be property understood. These have been explained already, so we will not go into that. What we will go into is how they look in the CI taxonomy.

10.10.7.1. Presentation of Tuples Below is a screenshot of a portion of the CI taxonomy which contains a tuple, ID 1206 through 1208:

You should note the following about this tuples:

Line Concept label Explanation ID 1206 Contingencies – Possible

Loss [Sequence] This is the tuple. Note that it is plural (but it really should be singular). The "stuff" inside a tuple relates to ONE loss contingency, not all loss contingencies. Notice the [Sequence] portion of the label. There are two types of composers, "All" and "Sequence"; FRTA says you must use "Sequence". So, basically, all tuples should say [Sequence]. Going any further would be delving into stuff which is too technical, so we won't go there. What follows is the "stuff" which is inside the tuple.

ID 1207 Contingencies – Nature of Possible Loss [1:1]

This line is somewhat of a "unique key" for the tuple. Each tuple should be unique. For example, why would you show information for the same loss contingency twice? That really makes no sense. Another point to note is [1:1] part of the string. What this indicates is the minOccurs value (the minimum number of times it can occur in the tuple which is one) and the maxOccurs value (which is the maximum number of times it must occur in the tuple, which is one). So basically, this value is REQUIRED. And this makes sense, as it is a key value.



Line Concept label Explanation ID 1208 Contingencies – Estimated

Possible Loss [0:1] Here you would put the estimated possible loss for the contingency. Note that this is optional [0:1] indicating that it must occur a minimum number of times of zero and it can only occur once. Therefore, this concept is optional.

So, there you have a description of a tuple. Concepts ID 1207 through ID 1208 are all items which exist inside the tuple concept "Contingencies – Possible Loss" which binds all the concepts together. Some concepts are optional, some concepts are required.

There are a few things one needs to understand about tuples. First, as already mentioned, it binds items or other tuples together to form complex, related data. Second, take a look at the tuple above. How many possible loss contingencies can an entity have? The possibilities are unlimited. A tuple can be used to capture repeating information with an unlimited number of possibilities. Contrast that to the concepts with IDs 1211 through 1214. That is a finite listing of concepts, exactly four. And, those concepts are totally unrelated, even though they look related to humans; computers don’t know they are related other than they are all children of the concept ID 1210.

10.10.7.2. Calculation of Tuples Now, tuples themselves cannot appear in calculations. Tuples contain no values, only wrap concepts together. However, concepts inside tuples can appear in calculations in two ways.

The first way is shown in the following. Consider the tuple below shown in a presentation report which is used to provide information for a class of common stock:

Consider the following calculation relationship:

In the two printouts ID 275 (on top) and ID 227 (on the bottom) "Common Stock – Value (Excluding Additional Paid in Capital)" are the same concept. Notice the weight on ID 227 of 1. There is a calculation relation between ID 227 and ID 226. ID 226 is an item which summarizes the value of all of the classes of common stock, for each of the tuples which might exist in an instance document. A company can have any number of classes of common stock. ID 226 appears on the balance sheet.

A second way that concepts inside a tuple can appear in a calculation is a simple calculation relationship between two components within the tuple. No screenshot is shown for this, it looks like a normal calculation described above.

These same concepts apply to all tuples within the USFRTF.



10.10.8. Understanding the Reconciliation (Movements Analysis)

Another somewhat "funky" piece of the CI taxonomy and the USFRTF is the reconciliation (or sometimes called a movement analysis). This is explained below.

10.10.8.1. Presentation of Movement Analysis The following is a screenshot of a reconciliation (movement analysis) for a portion of the statement of stockholders' equity from the presentation report:

The table below explains the pieces of this reconciliation:

Line Concept label Explanation ID 805 Increase/(Decrease) in

Treasury Stock - Value This is an abstract concept whose purpose is to help organize the reconciliation. If you look at its three children, you can see the parts of a reconciliation; a beginning balance, increases or decreases (changes), and an ending balance.

ID 806 Treasury Stock Value – All Types and Classes – Beginning Balance

A reconciliation has three major pieces: a beginning balance, increases and decreases (changes), and an ending balance. This concept is both the beginning balance and the ending balance, see ID 817. These are both the same concept, but with different preferred label roles. Note that both the beginning and ending balance have periodType values of instant.

ID 807 Treasury Stock – Value – Increase/(Decrease)

This concept is an abstract element whose purpose is to provide a spot to hook all the concepts which comprise the changes to, including the total changes, see ID 816.

ID 808 through ID 815

Various labels These are the actual detail changes in the reconciliation. Note that these concepts don’t have a balance attribute, but they should. Note that the changes have a periodType value of duration.

ID 816 Increase/(Decrease) in Treasury Stock – Value - Total

This concept is the total of all the increases and decreases (changes) of the reconciling concepts.



Line Concept label Explanation ID 817 Treasury Stock Value – All

Types and Classes – Ending Balance

Again, this concept is the same concept as ID 806. The only difference is that the preferred label shown in the presentation printout is for the ending balance. Note that the ending balance is has a periodType of instant.

That is all there is to a reconciliation (movement analysis) from a presentation perspective. Next, we look at the calculations relating to the reconciliation (movement analysis).

10.10.8.2. Calculation of Movement Analysis Although XBRL cannot be used to express all the relationships of a movement analysis, it can express the calculation of the total changes concept. Note the calculation printout below.

The following describes the calculation printout:

Line Concept label Explanation ID 729 Increase/(Decrease) in

Treasury Stock – Value - Total

This is the concept which holds the value for the total changes of a reconciliation (movement analysis). Note that this concept is the same concept as ID 817 in the presentation report. Note that the label is different as a total's preferedLabelrole is being used on the presentation report.

ID 730 through ID 737

Various labels These concepts make up the details of the changes. Note the correlation between the weights (values of 1 or -1) and the balance attribute (values of D for debit or C for credit). Note that all debits are 1 and all credits are -1. (As these don’t have balance attributes, you cannot see the correlation; but these really should have balance attributes.) Further note that these are the same concepts as ID 808 through 815 on the presentation report.

Again, the relationship of the detailed changes to total changes can be expressed using XBRL calculations, thus the beginning and ending balance and how they relate to the changes is not shown in the calculation report.

However, although the contexts of the beginning balance, the total changes, and the ending balance cannot be expressed using XBRL calculation linkbases, they can be expressed using XBRL formulas when that specification is released or using proprietary formula linkbases now available.



10.10.9. Other Taxonomy Components Items, tuples and movement analyses cover 98 percent of the CI taxonomy and the USFRTF. There are a few other patterns in the taxonomy, but we will not cover these here. For more information about these and other patterns, see "The Patterns Document" which has a through explanation of all of these patterns which are used in financial reporting taxonomies.

The following characterizes the small percentage of concepts which are not covered by the above:

• Movement analysis within a tuple

• Nested tuples, or a tuple within a tuple

10.11. Extension to USFRTF - Strategies Now we will discuss industry and company extensions to the CI taxonomy or the USFRTF. For example, the airlines industry might create an extension to the CI taxonomy as the current USFRTF does not have an airlines taxonomy. Or, the restaurant industry may create an extension, one which would probably never be built by XBRL-US as it may be deemed to detailed for the USFRTF.

In addition, the US Securities and Exchange Commission may choose to use the USFRTF. If so, they will have to extend the USFRTF as SEC filings are above and beyond the financial information provided by the USFRTF. Or, the SEC may not agree with certain components of the USFRTF, so they could possibly create an extension taxonomy to change the USFRTF.

Or, a company will create an extension of the taxonomy to meet their specific reporting needs.

There are also other possible occasions when an extension taxonomies being created. Here, we discuss issues relating to extension taxonomies.

10.11.1. Overview There are a number of options to be considered by those wishing to create extensions to the USFRTF. There currently is no official mandate as to the appropriateness of the various options. Some mandate will perhaps exist in the future and that mandate will likely come thanks to experience using the USFRTF.

There are many factors which come into play when deciding the best way for a extension to be built. Some of these factors to be considered are the following:

• Ongoing maintenance – Taxonomies will always need maintenance. Having to rely on the owners of the base taxonomy and not being able to do updates on the base taxonomy, unless the owners do it first, could motivate some of those desiring to create extensions, to simply create their own taxonomies, rather than extend the USFRTF.

• Intellectual Property Rights – Intellectual property rights (IP rights) may be a consideration when those who wish to create extensions make the choice whether to extend a taxonomy or create a separate taxonomy but then map to the base USFRTF.

• Resources of Those Creating Extension – The fewer the resources group wishing to create an extension has, the more likely the group will simply use the USFRTF and create the "marginal" extension they need; rather than creating their own taxonomy which they would then need to maintain.



• Flexibility Desired – The more flexibility which is desired, the more a group or company might create a new taxonomy, rather than "rewire" an existing taxonomy, or components of a taxonomy. This also will be determined by the flexibility built into the USFRTF. The more flexible it is, the higher the probability that groups will choose to extend the taxonomy, rather than create new taxonomies. On the other hand, if a group cannot use the components provided as desired, they may choose to create a separate new taxonomy.

• Appropriateness of Taxonomy Concepts – The appropriateness of the taxonomy concepts will be a determining factor in the decision to extend or create new concepts and map. For example, the CI taxonomy has 1,590 concepts. If a group only needs, say, 100 concepts from the CI taxonomy, it could be better to create 100 new concepts in their taxonomy and then map to the CI taxonomy. If the "overhead" of having the other 1,490 unwanted concepts "clutter" the extension taxonomy hurts usability as a result, this could be a reasonable option.

• How Good Mapping Features Work – Another consideration will be how good mapping works as compared to using the same concepts. If the same end result can be arrived at using both methods, then both creating a new stand-alone taxonomy and then mapping and extending have very little difference.

The following is a summary of the spectrum of extension options. This list places no judgments as to the appropriateness of any option; it only articulates the different options. Different groups will likely do what they consider to be best for them, all things considered (we will use the CI taxonomy for discussion purposes here, but these concepts apply to the entire USFRTF):

• Don’t Allow Extensions – One option is to simply not allow extensions. This might occur if a group has no additional information it desires to add to the CI taxonomy and the group desires to use the CI as a "form", nothing can be added. For example, a commercial lender could require information to be reported only for concepts which exist in the CI taxonomy.

o High level of trust that CI taxonomy will be properly maintained.

o High correlation between what the group's desires and what the CI taxonomy has provided.

• Create New, Stand-alone Taxonomy – Another option in extending the CI taxonomy is to literally "take a copy" of it (although be aware of intellectual property issues), change the namespace identifier and namespace prefix, create a totally new taxonomy, delete what is not desired, add additional concepts required, and create a totally new taxonomy. Another step might be to then map the new taxonomy to the CI taxonomy. This approach might be used by a group if:

o High desire for control over maintenance.

o High desire for flexibility.

o Have available resources.

o Low level of confidence that CI taxonomy will be properly maintained.

• Create Extension Taxonomy, Leverage Relationship Linkbases – Another option is to create an extension taxonomy which references the existing CI taxonomy, then "extend" the taxonomy adding concepts they



desire in addition to what exists and prohibiting what they do not desire in their taxonomy. This option includes leveraging the existing presentation and calculation linkbases in addition to the taxonomy concepts.

o High level of trust that the CI taxonomy will be well maintained and there is a reliable, periodic release schedule.

o Appropriate level of flexibility exists for the CI taxonomy components.

o Linkbases are very close to what the extending group desires.

o High level of trust that the CI taxonomy will be properly maintained.

• Create Extension Taxonomy, Create New Relationship Linkbases – Another option, which is similar to the previous option, is to leverage the taxonomy concepts (the schema files) and label and reference linkbases; but then create new presentation and calculation linkbases.

o Low level of correlation between what exists in the presentation and calculation linkbases as compared what is needed by the extending group.

o High level of trust that the CI taxonomy will be well maintained.

• Create Extension Taxonomy, Create all New Linkbases – This option takes the previous option one step further. The concepts are used (from the schema file) but none of the linkbases are desired to be reused: no labels, references, presentation relations or calculation relations.

o High level of correlation with concepts, but low level of correlation with labels, references, presentation relations, calculation relations desired.

o High level of trust that CI taxonomy will be well maintained.

So, again, the above articulates the spectrum of possible options and provides no judgments as to what taxonomy extension options a group or company might use when extending the CI taxonomy, or any part of the USFRTF. It is highly likely that different groups will choose different options; therefore all of these options will perhaps exist. Over the years, as more information is learned, some options may fall from favor. Time will tell.

10.12. Industries

10.12.1. AICPA Audit Guides The USFRTF has not officially defined the industries they will create for the USFRTF. It is anticipated that, possibly, the official list of industries is the audit guides published by the American Institute of Certified Public Accountants (AICPA). That list of industries is:

AICPA Audit Guides Agricultural Producers and Agricultural Cooperatives Airlines Banks and Savings Institutions Brokers and Dealers in Securities Casinos Common Interest Realty Associations Construction Contractors Credit Unions



Employee Benefit Plans Entities with Oil and Gas Producing Activities Federal Government Contractors Finance Companies Health Care Organizations Investment Companies Property and Liabilities Insurance Companies Service Organizations Not-for-Profit Organizations State and Local Governmental Units Personal Financial Statements

10.12.2. SEC Regulations Another possible industry list are those defined by the US SEC:

AICPA Audit Guides Reg S-X Article 5 Commercial and Industrial Companies Reg S-X Article 6 Registered Investment Companies Reg S-X Article 6A Employee Stock Purchase, Savings and Similar

Plans Reg S-X Article 7 Insurance Companies Reg S-X Article 9 Bank Holding Companies

10.12.3. More Detailed Breakdown Another possibility for the industry buildout of the USFRTF would be a more detailed list, such as:

Advertising Aerospace & Defense Air Courier Airline Apparel/Accessories Appliance & Tool Audio & Video Equipment Auto & Truck Manufacturers Auto & Truck Parts Beverages (Alcoholic) Beverages (Non-Alcoholic) Biotechnology & Drugs Broadcasting & Cable TV Business Services Casinos & Gaming Chemical Manufacturing Chemicals - Plastics & Rubber Coal Communications Equipment Communications Services Computer Hardware Computer Networks Computer Peripherals Computer Services Computer Storage Devices Conglomerates Construction & Agricultural

Machinery Construction - Supplies & Fixtures Construction - Raw Materials Construction Services Consumer Financial Services Containers & Packaging Crops Electric Utilities Electronic Instruments &

Controls Fabricated Plastic & Rubber

Fish/Livestock Food Processing Footwear Forestry & Wood Products Furniture & Fixtures Gold & Silver Healthcare Facilities Hotels & Motels Insurance (Accident & Health) Insurance (Life) Insurance (Miscellaneous) Insurance (Prop. & Casualty) Investment Services Iron & Steel Jewelry & Silverware Major Drugs Medical Equipment & Supplies Metal Mining Misc. Capital Goods Misc. Fabricated Products Misc. Financial Services Misc. Transportation Mobile Homes & RVs Money Center Banks Motion Pictures Natural Gas Utilities Non-Metallic Mining Office Equipment Office Supplies Oil & Gas - Integrated Oil & Gas Operations Oil Well Services & Equipment Paper & Paper Products Personal & Household Prods. Personal Services Photography Printing & Publishing Printing Services Railroads Real Estate Operations Recreational Activities Recreational Products Regional Banks Rental & Leasing Restaurants Retail (Apparel) Retail (Catalog & Mail Order) Retail (Department & Discount) Retail (Drugs) Retail (Grocery) Retail (Home Improvement) Retail (Specialty) Retail (Technology) S&Ls/Savings Banks



Schools Scientific & Technical Instruments

Security Systems & Services

Semiconductors Software & Programming Textiles - Non Apparel Tires Tobacco Trucking Waste Management Services Water Transportation Water Utilities

So, the actual industry breakdown is still to be determined, but it will likely be somewhere between the industry audit guides of the AICPA and the longer list of industries, which provides more detail. It could be the case that, for example, the USFRTF uses the industry audit guides list, but then another group provided a more detailed set of industries, perhaps the industry associations might do this.

10.13. Extending the USFRTF – Details to Consider The purpose of this section is to discuss the overall views of how the creators of the taxonomy see how the taxonomy will likely be extended and to discuss extending the CI taxonomy as an example of how the USFRTF in general would be extended. This discussion does not show you how to extended a taxonomy, it discusses more bigger picture issues and just general ways to see the taxonomy and therefore how to determine your extension route.

The reasoning for this discussion is that if you know how the taxonomy was designed to be extended, you will likely be more successful in actually extending the taxonomy.

10.13.1. Overview of Extending The CI taxonomy and the USFRTF was built to be extended. It is impossible for the creators of the USFRTF to provide everything which every industry or company would require to report their financial information.

It has tried to provide features which make extension easier, rather than more difficult. In addition, it has tried to minimize the necessity for extension. For example, as many subtotals as possible were provided, rather than not providing the subtotals, thus requiring extension of the taxonomy to have the subtotals.

In general, as a user moves down in the taxonomy hierarchy, the probability for the need to extend the taxonomy would increase. Higher level concepts and relationships are less likely to be extended. For example, if you are extending the high levels such as "Assets" or "Liabilities and Equity", then something is likely being seen incorrectly or you are inventing new accounting concepts.

On the other hand, at the lower levels, or leaf levels, it is impossible for the taxonomy creators to anticipate and provide for all of the possible options required by reporting entities. For example, consider the concepts "Accrued Expenses", "Other Operating Revenue", and "Other Assets - Current". Clearly, these lists are endless and more unique to specific reporting entities than higher level concepts such as "Assets". If a group, or industry, or company has a list they wish to add, then can do so by creating these concepts and relationships in their extension to the CI taxonomy or other taxonomy in the USFRTF.

Professional judgment of an accountant clearly supersedes any discussion here; these are simply offered as things to consider. Materiality plays a role in these decisions also.

It may be the case that reporting entities will choose to report concepts on the face of, say, the income statement which could be reported within the notes. XBRL really has no formal mechanism to distinguish "presentation on the face of the financial statements" and "disclosure within the notes. Perhaps it should, but it currently does not.



Additionally, XBRL has no mechanism for distinguishing between what has been audited and what has not been audited.

The closest conceivable thing to distinguishing "presentation" and "disclosure" is where concepts appear in the presentation linkbase. However, this is not a formal distinction. Perhaps this distinction will be made more formal over time. Or perhaps, the distinction is less important as the paper-reporting mechanism becomes electronic with no concept of "face" and "disclosures".

So, next we take a look at extensions to the CI taxonomy by section of the taxonomy, using extended links.

10.13.2. Balance Sheet (Statement of Financial Position) The balance sheet is fairly straight forward. There are simply lists of assets, liabilities, equity concepts and fairly straight forward calculations. There does tend to be a lot of levels in the balance sheet or "sub totals".

Common extension tasks that might be for users of this taxonomy may include the use of extensions to combine two line items on the balance sheet into one for materiality reasons or add additional detail line items. It is highly unlikely that higher level concepts such as "Assets", "Liabilities", and "Equity" are added to, removed, or rewired.

The following are some other thoughts relating to extending the balance sheet.

• A balance sheet contains "Assets", "Liabilities" and "Equity". Inventing a new concept such as "Other stuff which I don’t want to put under assets or liabilities and equity" should probably not be created; unless, of course, the accounting pronouncements change to include such a concept.

• Within the balance sheet and the category "Assets", there are line items which are required to be disclosed on the face of the balance sheet such as "Property, Plant and Equipment", "Intangible Assets" and "Prepaid Expenses". It is highly unlikely that "Property, Plant and Equipment" and "Prepaid Expenses" should be combined and show the combined total, "Property, Plant, Equipment and Prepaid Expenses". There are cases where this may be appropriate, but all things considered, it would be unusual. In addition, it would be unusual to add a new category such as "Foo" at the same level as "Property, Plant and Equipment". There is a high degree of probability that at that higher level of detail, all the categories of assets (and liabilities and equity) are contained on the balance sheet.

• It is likely that a conglomerate which is both a financial institution but also a commercial and industry entity (a hybrid) will have to create extensions to express their balance sheet. A combined commercial and industrial and financial institution balance sheet is considered rare and not provided in the USFRTF.

The stockholder's equity section of the balance sheet does have one thing which should be explained. Consider the following presentation printout fragment:



What you see above is the ending of the liabilities section, note ID 269 "Liabilities – Total", and then the beginning of the stockholder's equity section. In the liabilities and assets sections, there are nothing but items in the taxonomy. However in the equity section, you have some tuples, see ID 273 through 280. The tuples are used to capture information relating to classes of stock. Each tuple is positioned under the line item which it provides more detailed information for. In the case above, the tuple with ID 273 through 280 provides detail for ID 272, therefore it is a child of that concept in the presentation printout. The calculation printout shows the line items a bit more clearly.

10.13.3. Income Statement The income statements will likely be extended in a similar manner to the balance sheets. However, as there are far, far more relationship structures and levels in the income statement, users may be "picky" as to the wiring of how they desire their income statement to appear.

Based on observations obtained in the actual construction of the CI taxonomy, the amount of real differences which should exist within income statements is lower than one might think. When push came to shove, many people simply had incorrect perceptions as to how an income statement should be constructed.

The CI taxonomy contains an income statement which resulted from a large amount of "negotiation" as to where things belong. Users should consider this and if their professional judgment tells them they need to rewire something in the income statement, then they should certainly follow their professional judgment. On the other hand, the existing structure and wiring can be well justified. You should be able to justify any rewiring which is created in an extension taxonomy.

What this means is that, care and consideration should be used when moving a concept from operating income to non-operating income. These decisions are based on accounting rules, not XBRL.

10.13.4. Cash Flows The cash flows statement is rather straight forward. One thing to realize is that two options are provided in the CI taxonomy as there are two options on how this statement can be created: direct method or indirect method.

It is highly unlikely that a new category of cash flow would be added to the taxonomy: "Operating Activities", "Investing Activities" and "Financing Activities" are all that are currently catered for in the taxonomy. Therefore, it is highly likely that all extensions will be done within one of those categories.



Within one of those categories of cash flows, it is very possible that something might need to be added.

The most confusing area of the taxonomy, because it is a rather confusing area of financial reporting, is the section "Net Cash Flow Provided By/(Used In) Operating Activities, Indirect". This results from the complexity in this area of the indirect cash flow statement, thus also a complex area of the taxonomy. In the author's view, errors in this area of the taxonomy are twice as likely as in other areas of the taxonomy.

10.13.5. Statement of Changes in Equity The statement of changes in equity looks overwhelming in the taxonomy, but it really is fairly straight forward when you look at the pieces. There are lots of pieces, but the pieces are small and well organized.

Rewiring the statement of changes in equity might be one of the most difficult extension tasks a reporting entity will undertake. The reason for this is based on all the relations involved and the complexity of the reconciliation, which is what the statement of changes equity is; one big reconciliation.

10.13.6. Notes to the Financial Statements The notes to the financial statements contain the accounting policies and explanatory disclosures of a financial statement.

The accounting policies are fairly easy to extend as they contain very few calculation relationships and only a few tuples. Calculations and tuples make taxonomies more complicated to understand. But once you understand calculations and tuples, this is very manageable.

The USFRTF in general, and the CI taxonomy specifically do not have the accounting policies or explanatory disclosures built out yet to the degree that they need to be. Some policies and disclosures are built out.

One of the challenging areas for creating instances for policies will be that the information for accounting policies is textual in nature. At times, accountants tend to group lots of "stuff" (particularly things which are immaterial) into a single paragraph or even into a single sentence.

How would this single sentence be expressed to "parse" the multiple disclosures into the separate concepts of the taxonomy? This will be one primary challenge.

The other primary challenge will be the opposite end of the spectrum where a single disclosure item is composed of several paragraphs of text, or something formatted as a list or bulleted list.

It is here in the accounting policies that we first run into the issue of separating data from presentation. Accountants will tend to desire the XBRL data to "look" like the presentation. This may not work will in all cases.

The explanatory disclosures have a lot in common with the accounting policies in that they contain lots of text. But, the explanatory disclosures are significantly more complicated than the accounting policies for the following reasons:

• Sheer volume of the disclosures; there are lots of disclosures,

• There are many calculation relationships in the explanatory disclosures, way more than the accounting policies,

• There are a significant number of tuples in the explanatory disclosures,

• There are lots of reconciliations in the explanatory disclosures,



• There are some fairly complicated tuples

• There are relationships between concepts within tuples to concepts outside the tuple.

Bottom line is that, take as a whole, the explanatory disclosures may be somewhat overwhelming, but if broken up into smaller pieces, those smaller pieces are actually smaller than sections like the balance sheet, income statement, and cash flow statement, etc.

It is important to see this to reduce the overwhelming feeling!

One thing relating to extending the explanatory disclosures and worth pointing out is the issue of extending information within a tuple. It is not that big a deal, but there are a few steps involved in the process. The fundamental reason why extending tuples is a bit more challenging is that tuples have a minimum amount of "content model", and the content model basically has to be reconstructed. There are several steps in the process of extending tuples:

1. Create any new concepts.

2. Rebuild the entire tuple.

3. Create a "similar-tuple" definition relation to point out that the new tuple you created is only slightly different than the tuple you are extending.

The reason for this is that you really cannot alter another taxonomy (a taxonomy which you don’t "own"). So, you have to actually create a new tuple and then use an XBRL mechanism to maintain comparability.

There are so many different components of explanatory disclosures that it is impossible to cover all of them here. However, the entire explanatory disclosures section can be broken out into specific "patterns". All of these patterns are discussed in "The Patterns Document" which has been mentioned several times. From there, you will learn to recognize the pattern and apply the concepts of that pattern to the specific section you are dealing with.

Again, the USFRTF and CI taxonomy are not as complete in the area of the accounting policies and explanatory disclosures, the primary financial statements are far more complete.

10.14. In Summary In summary, hang in there! XBRL is a new beast. It will take time to figure out how to tame the beast and make it work to serve the needs of the financial reporting supply chain, particularly the accountants who wish to, or have to, make use of XBRL to communicate financial information.

XBRL is still maturing, the USFRTF is still maturing, the software tools available are still maturing. There is no place to go but up. XBRL will definitely be part of the future of financial reporting. Struggling through this period will pay dividends in the near future.

XBRL software which exists today can be compared to early spreadsheet software, such as "Visacalc". Think of the differences between Visacalc and Excel 10.

Investing up front to understand the USFRTF prior to trying to use it for creating a financial statement using XBRL is required. There are no short cuts. To use XBRL correctly, it is critical to understanding how XBRL works.

This material only presents the very basics. It is only the beginning of a process for obtaining a true working knowledge of XBRL and the USFRTF.



At this stage of the evolution of XBRL and the USFRTF, it is important that more and more accountants understand XBRL so that the proper taxonomies can be created. Having the proper taxonomies is the first step in creating XBRL instance documents.

XBRL will evolve. It is still maturing. Over the coming years as XBRL is used more and more, the right way for XBRL to be used in financial reporting will be uncovered. Currently there are many opinions but little practical use of XBRL. It is only that use in real life situations which will answer outstanding questions.



10.15. Summary of USFRTF Taxonomy Locations and Components The following is a summary of each individual taxonomy and file which makes up the USFRTF:

Name

URL

Primary Terms Elements (usfr-pte)

XSD http://www.xbrl.org/us/fr/common/pte/2005-02-28/usfr-pte-2005-02-28.xsd Presentation http://www.xbrl.org/us/fr/common/pte/2005-02-28/usfr-pte-2005-02-28-presentation.xml Label http://www.xbrl.org/us/fr/common/pte/2005-02-28/usfr-pte-2005-02-28-label.xml Reference http://www.xbrl.org/us/fr/common/pte/2005-02-28/usfr-pte-2005-02-28-reference.xml Primary Terms Relationships (usfr-ptr)

XSD http://www.xbrl.org/us/fr/common/ptr/2005-02-28/usfr-ptr-2005-02-28.xsd Presentation http://www.xbrl.org/us/fr/common/ptr/2005-02-28/usfr-ptr-2005-02-28-presentation.xml Calculation http://www.xbrl.org/us/fr/common/ptr/2005-02-28/usfr-ptr-2005-02-28-calculation.xml Financial services Elements (usfr-fste)

XSD http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28.xsd Presentation http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28-presentation.xml Labels http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28-label.xml References http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28-reference.xml Financial services Elements (usfr-fstr)

XSD http://www.xbrl.org/us/fr/common/fstr/2005-02-28/usfr-fstr-2005-02-28.xsd XSD http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28.xsd XSD http://www.xbrl.org/us/fr/common/ptr/2005-02-28/usfr-ptr-2005-02-28.xsd Presentation http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28-presentation.xml Labels http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28-label.xml References http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28-reference.xml SEC Certification (usfr-sec-cert)

XSD http://www.xbrl.org/us/fr/rpt/seccert/2005-02-28/usfr-seccert-2005-02-28.xsd Presentation http://www.xbrl.org/us/fr/rpt/seccert/2005-02-28/usfr-seccert-2005-02-28-

presentation.xml Labels http://www.xbrl.org/us/fr/rpt/seccert/2005-02-28/usfr-seccert-2005-02-28-labels.xml References http://www.xbrl.org/us/fr/rpt/seccert/2005-02-28/usfr-seccert-2005-02-28-references.xml Management Report (usfr-mr)

XSD http://www.xbrl.org/us/fr/rpt/mr/2005-02-28/usfr-mr-2005-02-28.xsd Presentation http://www.xbrl.org/us/fr/rpt/mr/2005-02-28/usfr-mr-2005-02-28-presentation.xml Labels http://www.xbrl.org/us/fr/rpt/mr/2005-02-28/usfr-mr-2005-02-28-labels.xml Accountants Report (usfr-ar)

XSD http://www.xbrl.org/us/fr/rpt/ar/2005-02-28/usfr-ar-2005-02-28.xsd Presentation http://www.xbrl.org/us/fr/rpt/ar/2005-02-28/usfr-ar-2005-02-28-presentation.xml Labels http://www.xbrl.org/us/fr/rpt/ar/2005-02-28/usfr-ar-2005-02-28-labels.xml References http://www.xbrl.org/us/fr/rpt/ar/2005-02-28/usfr-ar-2005-02-28-references.xml



Name

URL

Management Discussion and Analysis (usfr-mda)

XSD http://www.xbrl.org/us/fr/rpt/mda/2005-02-28/usfr-mda-2005-02-28.xsd Presentation http://www.xbrl.org/us/fr/rpt/mda/2005-02-28/usfr-mda-2005-02-28-presentation.xml Labels http://www.xbrl.org/us/fr/rpt/mda/2005-02-28/usfr-mda-2005-02-28-label.xml References http://www.xbrl.org/us/fr/rpt/mda/2005-02-28/usfr-mda-2005-02-28-reference.xml Commercial and Industrial Companies (us-gaap-ci)

XSD http://www.xbrl.org/us/fr/gaap/ci/2005-02-28/us-gaap-ci-2005-02-28.xsd Presentation http://www.xbrl.org/us/fr/gaap/ci/2005-02-28/us-gaap-ci-2005-02-28-presentation.xml Calculation http://www.xbrl.org/us/fr/gaap/ci/2005-02-28/us-gaap-ci-2005-02-28-calculation.xml Banking and savings institutions (us-gaap-basi)

XSD http://www.xbrl.org/us/fr/gaap/basi/2005-02-28/us-gaap-basi-2005-02-28.xsd XSD http://www.xbrl.org/us/fr/common/fstr/2005-02-28/usfr-fstr-2005-02-28.xsd Presentation http://www.xbrl.org/us/fr/gaap/basi/2005-02-28/us-gaap-basi-2005-02-28-

presentation.xml Calculation http://www.xbrl.org/us/fr/gaap/basi/2005-02-28/us-gaap-basi-2005-02-28-calculation.xml Labels http://www.xbrl.org/us/fr/gaap/basi/2005-02-28/us-gaap-basi-2005-02-28-label.xml Insurance Entities (us-gaap-ins)

XSD http://www.xbrl.org/us/fr/gaap/ins/2005-02-28/us-gaap-ins-2005-02-28.xsd Presentation http://www.xbrl.org/us/fr/gaap/ins/2005-02-28/us-gaap-ins-2005-02-28-presentation.xml Calculation http://www.xbrl.org/us/fr/gaap/ins/2005-02-28/us-gaap-ins-2005-02-28-calculation.xml Labels http://www.xbrl.org/us/fr/gaap/ins/2005-02-28/us-gaap-ins-2005-02-28-label.xml Investment Management (us-gaap-im)

XSD http://www.xbrl.org/us/fr/gaap/im/2005-06-28/us-gaap-im-2005-06-28.xsd XSD http://www.xbrl.org/us/fr/common/ime/2005-06-28/usfr-ime-2005-06-28.xsd XSD http://www.xbrl.org/us/fr/common/fste/2005-02-28/usfr-fste-2005-02-28.xsd XSD http://www.xbrl.org/us/fr/common/pte/2005-02-28/usfr-pte-2005-02-28.xsd Presentation http://www.xbrl.org/us/fr/gaap/im/2005-06-28/us-gaap-im-2005-06-28-presentation.xml Calculation http://www.xbrl.org/us/fr/gaap/im/2005-06-28/us-gaap-im-2005-06-28-calculation.xml Labels Broker-Dealers (us-gaap-bd)

XSD (Not approved) Oil & Gas (us-gaap-og)

XSD (Not approved)

Chapter 10-understanding usfrtf

Documents

production financial

financial statements

xbrl ifrs

financial reportingknowledge

xbrl international

current usfrtf

use of financial information

xbrl instance documents