Chapter 10-understanding usfrtf

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

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.

© 2006 UBmatrix, Inc 203


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 Not provided
Cooperatives



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 us-gaap-ins
Companies
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.xml
usfr-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.xml
usfr-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.xml
us-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 Approved Contains common
Relationships 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 Approved Contains terms commonly
and Analysis 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 Approved Concepts and relationships
Industrial Companies to allow commercial and
industrial entities to
express their financial
statements.
us-gaap-basi Banking and savings Approved Concepts and relationships
institutions to allow banking related
entities to express their
financial statements.
us-gaap-ins Insurance Entities Approved Concepts and relationships
to allow insurance related
us-gaap-im Investment Approved Concepts and relationships
Management to allow investment
management related
entities such as mutual
funds to express their
us-gaap-bd Broker-Dealers DRAFT Concepts and relationships
to allow insurance related



us-gaap-og Oil & Gas Under Concepts and relationships
development to allow oil and gas related
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 Will likely be
and cooperatives added
us-gaap-air Airlines Will likely be
added
us-gaap-cas Casinos Will likely be
added
us-gaap-cira Common Interest Realty Will likely be
Associations added
us-gaap-cc Construction Will likely be
Contractors added
us-gaap-cu Credit Unions Will likely be
added
us-gaap-eb Employee Benefit Plans Will likely be
added
Federal Government Probably will not be a
Contractors separate taxonomy
us-gaap-fc Finance Companies Will likely be
added
us-gaap-hc Health Care Will likely be
Organizations added



us-gaap-so Service Organizations Will likely be
added

us-gaap-np Not for profit Will likely be
Organizations added, but
not in this
framework
us-gaap-slgu State and Local Will likely be
Governmental Units added, but
not in this
framework
us-gaap-pf Personal Financial Will likely be
Statements 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 http://www.xbrl.org/us/fr/gaap/ci/2005-02-28/us-gaap-ci-2005-02-28-calculation.xml
linkbase
us-gaap-ci Presentation http://www.xbrl.org/us/fr/gaap/ci/2005-02-28/us-gaap-ci-2005-02-28-
linkbase 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.xml
usfr-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
Cash Flow from Operations - Indirect
http://www.xbrl.org/us/fr/lr/role/CashFlowOperationsIndirect Method
http://www.xbrl.org/us/fr/lr/role/StatementCashFlows Statement of Cash Flows
Cash Flow from Operations - Direct
http://www.xbrl.org/us/fr/lr/role/CashFlowOperationsDirect Method

The following are defined by the Primary Terms Relations taxonomy:
Extended Link URI Extended Link Definition
Tuple Content Models - Common
http://www.xbrl.org/us/fr/lr/role/TupleContentModelsCommonTerms 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- xbrli:tokenItemType The value is restricted to one of the
ime:AffiliatedUnaffiliatedItemTy following values:
pe
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 This extended link network contains concepts to
Method use the indirect method of calculating net cash
flows from operating activities.
Cash Flow from Operations - Direct This extended link network contains concepts to
Method 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



Tuple Content Models - Common This extended link contains tuples, or complex
Terms 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.
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 Same as presentation linkbase.
Method
Cash Flow from Operations - Direct Same as presentation linkbase.
Method
Statement of Stockholders' Equity Same as presentation linkbase.



Total Stockholders' Equity This extended link calculations the "other
Calculation 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 This extended link contains tuples, or complex
Terms 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 Usage
http://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 The label of the concept is "Cash Equivalents"; the
Equivalents 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 This is the tuple. Note that it is plural (but it
Loss [Sequence] 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 This line is somewhat of a "unique key" for
Possible Loss [1:1] 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.



ID 1208 Contingencies – Estimated Here you would put the estimated possible
Possible Loss [0:1] 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:
ID 805 Increase/(Decrease) in This is an abstract concept whose purpose is
Treasury Stock - Value 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 A reconciliation has three major pieces: a
Types and Classes – beginning balance, increases and decreases
Beginning Balance (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 – This concept is an abstract element whose
Increase/(Decrease) 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 Various labels These are the actual detail changes in the
through ID reconciliation. Note that these concepts
815 don’t have a balance attribute, but they
should.

Note that the changes have a periodType
value of duration.
ID 816 Increase/(Decrease) in This concept is the total of all the increases
Treasury Stock – Value - and decreases (changes) of the reconciling
Total concepts.



ID 817 Treasury Stock Value – All Again, this concept is the same concept as
Types and Classes – ID 806. The only difference is that the
Ending Balance 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:
ID 729 Increase/(Decrease) in This is the concept which holds the value for
Treasury Stock – Value - the total changes of a reconciliation
Total (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 Various labels These concepts make up the details of the
through ID changes. Note the correlation between the
737 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 & Fabricated Plastic & Rubber
Controls
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 Security Systems & Services
Instruments
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/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/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

More Related Content

Similar to Chapter 10-understanding usfrtf (20)

More from jps619 (14)

Chapter 10-understanding usfrtf