ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo
FINANCIAL REPORTING USING XBRL – IFRS AND US GAAP EDITION (2006-03-01)




20. Advanced Aspects of XBRL
There are a number of advanced concepts relating to XBRL which are not
addressed in this material. These advanced concepts are summarized below so
the user of this document can be aware of them.

20.1. Extensibility Mechanisms – Customizing XBRL
The term "extensible" is part of the XBRL name.            XBRL offers three types of
extensions:
    1. Users can create their own meta-data by simply adding additional
       concepts to a taxonomy.
    2. Users can extend the meaning of specific types of XBRL meta-data. Roles,
       arcRoles, etc.
    3. Users can extend using many of the extension features of XML Schema.
    4. Users may create their own proprietary extension mechanisms.
To understand the true power of XBRL, pros and cons of each of these extension
mechanisms should be understood. These extensibility features of XBRL are
touched on in the XBRL specification, but not thoroughly discussed.
There are two aspects of these extensibility mechanisms which will be pointed out
here. The first is the XBRL Link Role Registry or LRR.

20.1.1.         Link Role Registry
The XBRL International Link Role Registry, or LRR, is an online listing of XLink
role and arcrole attribute values that appear in XBRL International acknowledged
and approved taxonomies. The LRR contains these roles and arc roles, along with
structured information about their purpose, usage, intended impact on XBRL
instance validation, and the location of conformances suite tests for testing
functionality of the roles and arc roles provided.
The LRR is a meta-data registry intended to help maximize comparability of
information in XBRL instance documents. It also standardizes the way this
metadata is read, reducing software development costs and complexity.

20.1.2.         XBRL Generic Linkbase
The second extensibility mechanism is the XBRL Generic Linkbase Specification.
If you look at the resource (labels, references, formulas, footnotes) and relation
type linkbases (presentation, calculation, definition) you will see more similarities
than differences. Yet, all of these linkbases are individually specified in the XBRL
2.1 specification.
The generic linkbase basically is one specification for expressing how linkbases
are to be built, and a method of specifying components (such as an attribute) and
other metadata (such as the value and meaning of a specific arcrole) needed by
individual linkbases.    The generic linkbase will likely be the longer-term
mechanism for specifying the base XBRL linkbases. But more importantly, it is a
standard way for specifying any linkbase which makes software more flexible.
Today, a user can create any extensibility mechanism they desire, but that
method would be proprietary to the user who created it. Software developers
could "copy" the way the presentation or label linkbases are constructed,
leveraging what their software already does, meaning if they build a proprietary




© 2006 UBmatrix, Inc                         502
FINANCIAL REPORTING USING XBRL – IFRS AND US GAAP EDITION (2006-03-01)



extension which is similar to the label linkbase, and their software can already
read the label linkbase, modifications to the software would be minimal to add
additional functionality.
But leveraging the existing specifications is more an ad hoc solution. The XBRL
Generic Linkbase solves the problem of consistent extensibility mechanisms,
creating a global standard way to create them.           This reduces software
development effort and enhances software interoperability.
Lastly, by creating the XBRL Generic Linkbase Specification, some features
wished for in the other linkbases can be added, making them more functional
than existing linkbases. For example, on feature the XBRL Generic Linkbase will
provide is the ability to attach a label(s) in multiple languages to basically
anything in an XBRL taxonomy or instance document. Currently, labels can only
be assigned to XBRL concepts in taxonomies.

20.2. Calculations
There are many issues relating to calculations, equality, etc which are not
discussed here, which are discussed in the XBRL Specification. For example,
performing calculations when decimals attribute values are different is one
example.

20.3. XBRL GL
XBRL GL, or the GL Taxonomy, is intended to enable the transfer of such things
as a chart of accounts, journal entries, historical transactions, a trial balance, job
costing information, payroll information, tax reports (book to tax reconciliations),
and other such information.       Generally, if data is found in a database of an
operational, business, or accounting system, it is probably appropriate to use
XBRL GL as a means for extracting and re-using that data. If the data is
summarized, filtered, calculated, then XBRL GL is perhaps not the best candidate
for use in data extraction. XBRL GL is somewhat of a "system" or "framework".
Other options could work, but XBRL GL is optimized for certain types of data and
if an application supports XBRL GL, it can provide significant leverage.
The home page for XBRL GL is:
                         http://www.xbrl.org/GLTaxonomy
Another very good source for XBRL GL information is the following URL:
                              http://www.gl.iphix.net/
This sight has a number of samples which facilitates an understanding XBRL GL.
The XBRL GL taxonomies and several instance document samples are provided in
this chapter's subdirectory.
XBRL GL does not require a standardized chart of accounts to gather information,
but rather can be used to bind together desperate systems in a global standard
way, rather than using proprietary ways. For example, it can be used to tie
together many different accounting systems used by different business lines
within an organization into the one system used for consolidation of the many
business units.
XBRL GL is a standard, 100% XBRL compliant, for exchanging general ledger
level transactions. While the term general ledger is used, this actually includes
subsidiary ledger transactions also, or rather exchanging subsidiary ledger
transactions to the general ledger.




© 2006 UBmatrix, Inc                        503
FINANCIAL REPORTING USING XBRL – IFRS AND US GAAP EDITION (2006-03-01)



20.3.1.         XBRL GL and Taxes
One of the interesting uses of XBRL GL was reported in the February 2006 issue
of Strategic Finance magazine in an article by Neal Hannon, "Will the IRS Be Next
to Adopt XBRL?" The article pointed out the following scenario and how XBRL
might help. Currently, seventeen companies have agreements with the US IRS
(Internal Revenue Service) to send transactions to the IRS before issues are
discovered in tax filings. The thought is that companies can proceed with
confidence that the IRS has full knowledge of transactions and any objections to
those transactions prior to the filing of a tax return. So basically, the IRS reviews
tax return information prior to filing to help ensure the filers are complying with
tax rules. This system is currently manual. The potential to expand this review
program, through the use of electronic reporting using XBRL, would help both
filers and the IRS.
The Strategic Finance article also points out that the US IRS has tax treaties with
more than 100 countries. Vast amounts of information are exchanged to report,
validate, and audit this information. This is one of the reasons the US IRS is
interested in XBRL GL, particularly since it is an international standard.

20.4. Storage and Archival of XBRL Information
Imagine to try and store XBRL information in an XML storage facility or within a
relational database. Imagine an entity reporting its financial information one
year, the taxonomy changing, reporting its financial information the next year
with the new taxonomy.
Imagine the same thing if the XBRL specification changes.
Project this over 5, 10, 25 years.




© 2006 UBmatrix, Inc                         504

More Related Content

Chapter 20-advanced aspectsofxbrl

  • 1. FINANCIAL REPORTING USING XBRL – IFRS AND US GAAP EDITION (2006-03-01) 20. Advanced Aspects of XBRL There are a number of advanced concepts relating to XBRL which are not addressed in this material. These advanced concepts are summarized below so the user of this document can be aware of them. 20.1. Extensibility Mechanisms – Customizing XBRL The term "extensible" is part of the XBRL name. XBRL offers three types of extensions: 1. Users can create their own meta-data by simply adding additional concepts to a taxonomy. 2. Users can extend the meaning of specific types of XBRL meta-data. Roles, arcRoles, etc. 3. Users can extend using many of the extension features of XML Schema. 4. Users may create their own proprietary extension mechanisms. To understand the true power of XBRL, pros and cons of each of these extension mechanisms should be understood. These extensibility features of XBRL are touched on in the XBRL specification, but not thoroughly discussed. There are two aspects of these extensibility mechanisms which will be pointed out here. The first is the XBRL Link Role Registry or LRR. 20.1.1. Link Role Registry The XBRL International Link Role Registry, or LRR, is an online listing of XLink role and arcrole attribute values that appear in XBRL International acknowledged and approved taxonomies. The LRR contains these roles and arc roles, along with structured information about their purpose, usage, intended impact on XBRL instance validation, and the location of conformances suite tests for testing functionality of the roles and arc roles provided. The LRR is a meta-data registry intended to help maximize comparability of information in XBRL instance documents. It also standardizes the way this metadata is read, reducing software development costs and complexity. 20.1.2. XBRL Generic Linkbase The second extensibility mechanism is the XBRL Generic Linkbase Specification. If you look at the resource (labels, references, formulas, footnotes) and relation type linkbases (presentation, calculation, definition) you will see more similarities than differences. Yet, all of these linkbases are individually specified in the XBRL 2.1 specification. The generic linkbase basically is one specification for expressing how linkbases are to be built, and a method of specifying components (such as an attribute) and other metadata (such as the value and meaning of a specific arcrole) needed by individual linkbases. The generic linkbase will likely be the longer-term mechanism for specifying the base XBRL linkbases. But more importantly, it is a standard way for specifying any linkbase which makes software more flexible. Today, a user can create any extensibility mechanism they desire, but that method would be proprietary to the user who created it. Software developers could "copy" the way the presentation or label linkbases are constructed, leveraging what their software already does, meaning if they build a proprietary © 2006 UBmatrix, Inc 502
  • 2. FINANCIAL REPORTING USING XBRL – IFRS AND US GAAP EDITION (2006-03-01) extension which is similar to the label linkbase, and their software can already read the label linkbase, modifications to the software would be minimal to add additional functionality. But leveraging the existing specifications is more an ad hoc solution. The XBRL Generic Linkbase solves the problem of consistent extensibility mechanisms, creating a global standard way to create them. This reduces software development effort and enhances software interoperability. Lastly, by creating the XBRL Generic Linkbase Specification, some features wished for in the other linkbases can be added, making them more functional than existing linkbases. For example, on feature the XBRL Generic Linkbase will provide is the ability to attach a label(s) in multiple languages to basically anything in an XBRL taxonomy or instance document. Currently, labels can only be assigned to XBRL concepts in taxonomies. 20.2. Calculations There are many issues relating to calculations, equality, etc which are not discussed here, which are discussed in the XBRL Specification. For example, performing calculations when decimals attribute values are different is one example. 20.3. XBRL GL XBRL GL, or the GL Taxonomy, is intended to enable the transfer of such things as a chart of accounts, journal entries, historical transactions, a trial balance, job costing information, payroll information, tax reports (book to tax reconciliations), and other such information. Generally, if data is found in a database of an operational, business, or accounting system, it is probably appropriate to use XBRL GL as a means for extracting and re-using that data. If the data is summarized, filtered, calculated, then XBRL GL is perhaps not the best candidate for use in data extraction. XBRL GL is somewhat of a "system" or "framework". Other options could work, but XBRL GL is optimized for certain types of data and if an application supports XBRL GL, it can provide significant leverage. The home page for XBRL GL is: http://www.xbrl.org/GLTaxonomy Another very good source for XBRL GL information is the following URL: http://www.gl.iphix.net/ This sight has a number of samples which facilitates an understanding XBRL GL. The XBRL GL taxonomies and several instance document samples are provided in this chapter's subdirectory. XBRL GL does not require a standardized chart of accounts to gather information, but rather can be used to bind together desperate systems in a global standard way, rather than using proprietary ways. For example, it can be used to tie together many different accounting systems used by different business lines within an organization into the one system used for consolidation of the many business units. XBRL GL is a standard, 100% XBRL compliant, for exchanging general ledger level transactions. While the term general ledger is used, this actually includes subsidiary ledger transactions also, or rather exchanging subsidiary ledger transactions to the general ledger. © 2006 UBmatrix, Inc 503
  • 3. FINANCIAL REPORTING USING XBRL – IFRS AND US GAAP EDITION (2006-03-01) 20.3.1. XBRL GL and Taxes One of the interesting uses of XBRL GL was reported in the February 2006 issue of Strategic Finance magazine in an article by Neal Hannon, "Will the IRS Be Next to Adopt XBRL?" The article pointed out the following scenario and how XBRL might help. Currently, seventeen companies have agreements with the US IRS (Internal Revenue Service) to send transactions to the IRS before issues are discovered in tax filings. The thought is that companies can proceed with confidence that the IRS has full knowledge of transactions and any objections to those transactions prior to the filing of a tax return. So basically, the IRS reviews tax return information prior to filing to help ensure the filers are complying with tax rules. This system is currently manual. The potential to expand this review program, through the use of electronic reporting using XBRL, would help both filers and the IRS. The Strategic Finance article also points out that the US IRS has tax treaties with more than 100 countries. Vast amounts of information are exchanged to report, validate, and audit this information. This is one of the reasons the US IRS is interested in XBRL GL, particularly since it is an international standard. 20.4. Storage and Archival of XBRL Information Imagine to try and store XBRL information in an XML storage facility or within a relational database. Imagine an entity reporting its financial information one year, the taxonomy changing, reporting its financial information the next year with the new taxonomy. Imagine the same thing if the XBRL specification changes. Project this over 5, 10, 25 years. © 2006 UBmatrix, Inc 504