1. Goals
The use of ·XBRL, the eXtensible Business Reporting Language, is increasing worldwide and business people are looking for information about its utility as well as the way it fits together. The goal of this document is to help those new to ·XBRL to understand the way that XBRL International (·XII) materials fit together, what to read and what not to read. Specifically, this document is intended to provide an overview of the various documents, processes and ·XML materials published by ·XII work together.
1.1 Intended audience
This document is primarily intended for a non-technical audience: preparers, managers, accountants and business people. It is also important reading for technical managers wishing to bring their teams up to speed on ·XBRL.
1.2 Document scope
This document encompasses ·XII publications both current and projected.
1.3 Document conventions
Editorial comments to be removed from final recommendations are denoted as follows:
WcH: This highlighting is used to indicate editorial comments about the current draft, prefixed by the editor’s initials.
Italics are used for rhetorical emphasis only and do not convey any special normative meaning.
1.4 Language independence
All ·XII documents are provided in UK English, but the ·ISC routinely grants permission to translate them into other languages.
2. Framework
A three-level framework is helpful for those trying to understand which parts of the XBRL framework relate to them. There are three layers of ·XBRL documentation, comprising:
1. a technical foundations layer,
2. a layer of modelling rules to guide advanced ·XBRL users as to how to use ·XBRL for applications such as financial or business reporting, and
3. a usage guidance layer that enables end-users to create ·XBRL documents.
Within these layers, the documents may be aimed at different audiences, either strictly software developers, mainly software developers, or primarily for accountants (or equivalent business users).
Figure 1. XBRL Documents
2.1 Technical Foundations (Level 1)
·XBRL is a technical language for defining and exchanging performance information about the financial or business operation of an organisation. It is built for that purpose exactly, is in use amongst an increasing number of regulators and market participants, and provides a very high degree of flexibility. Documentation of the technical foundations is most applicable to software and tool vendors that intend to develop ·XBRL parsers, validators or APIs, as well as software professionals that wish to interact with ·XBRL directly, without an abstraction layer of this sort. It is also important grounding for software professionals intending to evaluate, acquire and utilise these types of tools. Their contents are almost never relevant to accountants or reporting professionals.
Technical advice and interpretation on ·XBRL can be obtained by anyone via the XBRL-Dev discussion group (http://groups.yahoo.com/group/XBRL-DEV). The ·XII Specification Working Group (·SWG) monitors this list and is obliged to provide reasonable assistance through that forum.
Individuals employed by ·XII members may also access the ·SWG internal discussion group (http://groups.yahoo.com/group/XBRL-SpecV2) and the ·XII Domain Working Group (·DWG) corresponding discussion group (http://groups.yahoo.com/group/XBRL-Domain).
The ·SWG does intend to produce both a technical architecture document (analogous to the World Wide Web Consortium’s Web Architecture [W3A1]) and a technical roadmap for wider use, and these documents will be aimed at the technically minded.
2.1.1 XBRL Specification (http://www.xbrl.org/SpecRecommendations/)
The primary building block for ·XBRL is the ·specification. The ·specification sets out the technical rules for ·XBRL and is aimed primarily at advanced software professionals that are seeking to build tools that will directly consume or create ·XBRL documents. Many software developers will not come directly come into contact with the ·specification because they will use the library of processors and parsers that others provide and that simplify ·XBRL for specific purposes.
·XII publishes the ·specification. For the purpose of this document we are referring to XBRL 2.1. The XBRL International Steering Committee (·ISC) has declared that the ·specification will remain stable for at least two years from any point in time. Therefore, as of this writing, there will be no subsequent version beyond ·XBRL 2.1 until at least May 2007. The ·SWG has a tightly defined errata policy that can introduce editions with minor errata corrections at most every six months. The latest edition of the specification is dated 2005-04-25 [XBRL].
The ·specification is the most authoritative text in ·XBRL, but by nature is a complex technical document. Where there is an inconsistency between the ·specification and another part of the ·XBRL framework, the ·specification prevails. Clarifications of ·syntax, ·semantics and usage that are set out in the ·specification appear in other documents published by ·XII. Help for developers that are using the ·specification is guaranteed to be provided by the ·SWG, including the ·specification editors.
2.1.2 Conformance Suite (http://www.xbrl.org/SpecRecommendations/)
To assure the interoperability of ·XBRL materials, consistent interpretation of the ·specification by software developers is essential. The main control over these interpretations is the ·specification conformance suite. The conformance suite is a set of computer readable statements about specific aspects of the ·specification, usually in the form of small samples of ·XBRL that exercise different “boundary” or “edge” situations and potential misinterpretations. The conformance suite describes inputs and declares the required outputs to be produced by software correctly processing those inputs. By covering different aspects of the ·specification throughout the more than 280 tests, it is possible to ensure that different software products will all process ·XBRL files in the same way.
Note that statements about compliance with the conformance suite are self-certifications made by vendors. ·XII does not, at this time, evaluate vendor software products and declare them “·XBRL Compliant”.
2.1.3 Formula Functions
Software applications using ·XBRL can be more rapidly developed when there is a set of functions that can be used to extract pieces of information from a set of interrelated ·XBRL documents that all reference each other. Such functions are particularly valuable when developers need to write business logic, mathematical formulas, etc. A forthcoming module (subsidiary to the ·specification) will provide a list of functions, their definitions, and sample inputs and outputs.
2.1.4 Formula Linkbase
The forthcoming formula linkbase is a new, optional module of the ·specification that will allow the definition of complex computations, for validation (evaluating an expression to determine whether it is true or false) or derivation (evaluating an expression to calculate a new value). This provides an important building block for business rules that developers will need to program. Like the ·specification itself, the formula module is something predominantly of interest to specialist developers that are seeking to support the operation of this module in their tools which will, themselves, be used by applications that consume or produce ·XBRL materials.
2.2 Modelling Rules (Level 2)
While the foundation concepts of ·XBRL are mandatory, there is another layer of guidance materials that ·XII has developed and which assists the production of ·XBRL software applications (via the Ledger Taxonomy), the recording of the manner in which individual transactions roll up to journal and financial performance totals. Modelling rules, however they may be expressed in documents, provide detailed guidance as to how to use ·XBRL, the language, to model different kinds of reporting information for different software applications.
Documents at this level are relevant to software vendors seeking to produce, extend or consume taxonomies and produce or consume instance documents, including those basing their offerings on ·XBRL parsers, validators and APIs. Their principles are relevant to accountants and reporting professionals that act as ·taxonomy and/or ·instance document authors and consumers.
It is not mandatory to follow the guidelines set out in these documents. Rather, their use is something that ·XII strongly encourages. They are designed to enhance the interoperability of ·XBRL materials, and widespread adherence to them will ensure that it is simpler and easier to develop software that can produce and consume financial reports in ·XBRL.
·XBRL can be used for many types of reporting, including internal business performance reporting. However, the majority of ·XBRL reporting that is being conducted at present relates to financial statements and similar materials. The “Financial Reporting Taxonomy Architecture” (·FRTA) and the “Financial Reporting Instance Standards” (·FRIS) provide guidance on the production of taxonomies and instance documents respectively. As their names suggest, this guidance is for financial reporting only; ·FRTA and ·FRIS are focussed on that type of usage.
Advice about and interpretation of ·FRTA, the General Ledger ·taxonomy, and other documents at this layer can be obtained through the XBRL-Dev and XBRL-Public (http://groups.yahoo.com/group/XBRL-Public) discussion groups. The Working Groups, in particular the editors of ·FRTA and the General Ledger taxonomy, monitor these lists and are obliged to provide reasonable assistance through that forum.
Individuals employed by members of ·XII may also access the XBRL-Domain discussion group (for ·FRTA and ·FRIS topics) and the XBRL-GL discussion group (http://groups.yahoo.com/group/XBRL-GL) for General Ledger ·taxonomy topics.
2.2.1 Financial Reporting Taxonomy Architecture (FRTA) (http://www.xbrl.org/TaxonomyGuidance/)
The ·FRTA is a set of rules about the way that taxonomies should be constructed for maximum interoperability. The document is aimed at software developers and advanced ·taxonomy developers. Many of the rules can be incorporated into “·taxonomy builder” software automatically, although others require a degree of human judgment and interpretation.
The ·FRTA is enforced through the application of the ·Taxonomy Recognition Process (TRP), which makes conformance with the principles set out in the guidelines mandatory for those taxonomies that seek to be recognised as “Approved” by ·XII.
There is no obligation on ·taxonomy authors to seek Approved status for their work. However, most ·XII ·jurisdictions have committed to do so. There are incentives (in terms of ease of consumption) for software developers and ·taxonomy authors who can merely extend an existing ·taxonomy to conform to FRTA while never considering seeking Approval from ·XII.
2.2.2 FRTA Conformance Suite (http://www.xbrl.org/TaxonomyGuidance/)
Like the ·specification itself, the ·FRTA has an accompanying conformance suite that provides a computerised representation of the bulk of the ·FRTA rules. There are some 120 conformance suite tests that vendors need to apply.
Statements about compliance with the ·FRTA conformance suite are self-certifications made by vendors. ·XII does not evaluate nor certify vendor tools for compliance; it does, however, require that two different implementations pass the conformance suite before ·FRTA itself can be finalised.
2.2.3 FRIS – Financial Reporting Instance Standards (http://www.xbrl.org/InstanceGuidance/)
The ·FRIS is a set of rules regarding the way that an ·instance document should be constructed for maximum interoperability. ·FRIS is primarily aimed at software developers that are seeking to build offerings that generate XBRL data, although clearly software developers building offerings that consume XBRL data benefit from adherence to the standards as well.
·FRIS is subsidiary to ·FRTA, in the sense that ·FRTA conformant taxonomies will allow the production of ·FRIS conformant ·instance documents. Unlike the ·FRTA, however, there is no special inducement to ensure that tools build instances in conformance with ·FRIS. It is likely that common sense will prevail and ·FRIS will maximise the interoperability of financial reporting data.
2.2.4 FRIS Conformance Suite (http://www.xbrl.org/InstanceGuidance/)
Like the ·specification and ·FRTA, ·FRIS has a conformance suite to aide the development of software products that conform to the guidelines.
The same statements about vendor self-certification apply (see above).
2.2.5 Link Role Registry (LRR) (http://www.xbrl.org/LRR/)
XBRL provides a set of standard roles and arc roles that may appear in XBRL documents. As XBRL applications emerge, link roles with common and useful semantics appear. The XBRL Link Role Registry is a public, online data set that documents these roles and their usage. The link role registry is the mechanism by which new definitions and rules of usage can be added to FRTA, and may be expected to have frequent additions.
2.2.6 LRR Conformance Suite
The LRR is not a complex database, but does warrant having its own distinct tests, so that XBRL tools can be identified as to whether they support online access to the LRR while processing XBRL documents.
2.2.7 GL Taxonomy (http://www.xbrl.org/GLTaxonomy/)
The General Ledger ·taxonomy is a fully compliant ·XBRL ·taxonomy for the specific purpose of recording and exchanging individual transactions associated with business activities, which, in aggregate will become reporting concepts. The GL ·taxonomy allows the interoperable exchange of ledger, sub-ledger and other transactions, as well as the creation of reports based on the performance information that can be derived from these items in aggregate. It is a powerful, flexible tool for internal reporting, data consolidation and e-commerce. http://www.xbrl.org/GLTaxonomy/ is the home page for the GL ·taxonomy, and http://groups.yahoo.com/group/XBRL-GL/ is the ·XII members-only discussion group.
A GL conformance suite is currently being contemplated.
2.3 Usage Guidance (Level 3)
For many users of ·XBRL, the only ·XII materials they will ever refer to resides on this, the third level of the stack, because they will be able to rely on the authoritative implementation of the technical rules of ·XBRL by their chosen software tools.
Their use is not mandatory, merely strongly encouraged. Once again, the purpose in encouraging the consistent application of the principles set out in these documents is to maximise the interoperability of ·XBRL materials that end-users create and consume.
This layer is most relevant to accountants and reporting professionals seeking to use ·XBRL tools to produce or consume high quality electronic reports.
2.3.1 Jurisdictional Taxonomy Guidance
Individual ·jurisdictions are increasingly publishing their own ·taxonomy development guidance materials. These guides typically are designed to help those involved in the creation of jurisdictional taxonomies as well as ·extension taxonomies that expand on the base set of definitions that the ·jurisdiction has created.
2.3.2 Preparers Guide
The ·XII preparers guide will set out suggestions about the best way to ·tag data with ·XBRL ·taxonomy concepts and the best way to extend ·XBRL taxonomies.
These guidance materials are intended for accountants and reporting professionals. ·XII strongly encourages their use, but in a range of circumstances, they will not be applicable, for example where a national securities regulator sets out its own guidance materials or requirements.
2.3.3 Jurisdictional Instance Guidance
Individual ·jurisdictions are also increasingly publishing instance guidance materials, to guide the consistent construction of ·instance documents using the taxonomies of local relevance.
2.3.4 General Ledger Conceptual Guide
There are a wide range of guidance materials available for those using the General Ledger ·taxonomy, including a conceptual guide; the full listing, at
http://finance.groups.yahoo.com/group/XBRL-GL/files/XBRL-GL%20Documents%20Inventory.xls
is available to ·XII members.
3. Glossary
The terminology used in XBRL often overlaps with other terms.
·context |
The information that allows a fact or set of facts to be understood in relation to other information. Context needs to be identified inside an ·instance document and typically includes time, organizational entity, reporting segment, and scenario - whether the fact is budget, actual, interim, or final. |
·DTS |
The discoverable ·taxonomy set consists of files that are related, typically as interlocked modules. Both taxonomies and instance documents can refer or import other taxonomies so as to re-use concepts that have been defined elsewhere. A DTS is a mechanism in ·XBRL that facilitates this re-use. |
·DWG |
The ·XII Domain Working Group. This is a (members only) standing committee that is charged with (1) facilitating the creation and adoption of taxonomy best practice; and (2) gathering business requirements for ·XII. It does this through a range of guidance materials as well as a number of communication and outreach initiatives. Not to be confused with jurisdictional domain committees, which are often (but not always) set up in a ·jurisdiction to manage the creation of a local GAAP ·taxonomy. |
·element |
The base definition in a ·taxonomy of a single category of facts. |
·extension |
A ·taxonomy that is developed by an organisation to add corporate-unique concepts or to modify default taxonomy relationship structures. An extension is often used merely to add a concept to those available in a GAAP set of disclosures to take account of the particular circumstances of an organisation. This is generally to allow market differentiation of a particular market participant. However, extensions are also used to modify a base ·taxonomy for the purposes of a particular reporting organization. For instance, a company may choose to use a different label for a standard GAAP ·taxonomy, or to alter the way that a sub-total is calculated, to take account of company-specific circumstance. Most companies involved in reporting to securities regulators will choose to use extensions. |
·FRIS |
Financial Reporting Instance Standards are a set of guidelines for the preparation of high quality, highly interoperable ·XBRL ·instance documents. The majority of FRIS guidelines can be implemented by way of software that creates instance documents, so is properly regarded as a supporting set of materials. FRIS conformance can be tested by way of a specialist set of conformance suite tests. |
·FRTA |
Financial Reporting ·taxonomy Architecture. A long title for the ·taxonomy best practices document created largely by the ·DWG. FRTA aims to ensure that taxonomies that are built around the world use ·XBRL in some specific ways. This is in order to improve the interoperability of those taxonomies and to simplify the software development process for tools that need to process financial taxonomies. FRTA only relates to Financial Reporting taxonomies. These best practices are strongly encouraged by way of the ·Taxonomy Recognition Process (TRP). To reach the recognition level of “Approved”, it is necessary for a ·taxonomy to be FRTA conformant. FRTA conformance can be tested by way of a specialist software conformance suite, as well as a range of manual checks. |
·IASB |
The International Accounting Standards Board. See also ·IASCF. |
·IASCF |
The International Accounting Standards Committee Foundation. The governing body of the IASB. The IASCF has sponsored a range of IFRS related ·XBRL activity by both volunteers and staff, including the creation of the IFRS ·taxonomy. |
·IFRS |
International Financial Reporting Standards; see http://www.iasb.org.uk for more information. |
·instance document |
Instance documents are also called ·XBRL Data Documents, and are sometimes shortened to IDs (this is to be discouraged as “ID” has a special meaning in the ·specification). Instance documents contain one or more sets of ·context information that allows the consistent identification of: · the organisation(s) that are reporting information · the date(s) for which information is being reported; and the · details of any segments (such as the different divisions that are reporting inside a single organisation) and details of any scenarios (such as “budget” figures, “forecast” figures and “actual” figures) that are being used. Instance documents must also contain one or more unit identifiers that define the units of measure in use: typically currencies, but can also be physical or derived measures such as BrakeHorsePower, Meters and Shares. Finally, and most importantly, instance documents contain a “set of facts” that comprise a set of tags that are used by a ·taxonomy, the data that relate to those tag concepts and the identifiers that place the information in context. |
·ISC |
The International Steering Committee of ·XII. The governing body, in effect a board of directors, with membership elected by ·jurisdictions (for Jurisdictional seats) and the ·ISC itself for “at large” representatives. |
·jurisdiction |
Self-governed, generally country-specific not-for-profit organization, recognised as the peak ·XBRL authority in that area by ·XII by way of vote of the ·ISC. Jurisdictions (for a list see http://www.xbrl.org/jurisdictions.aspx) must agree to the XII branding and intellectual property policies. Jurisdictions bring together a diverse range of organisations, from report preparers through to software vendors, intermediaries, accountants, accounting organizations and official bodies, such as regulators and accounting standards setters. Since some of these organisations compete with each other, it is necessary for a suitable neutrally regarded facilitator to simplify the operation of the jurisdiction. Jurisdictions can be not-for-profit companies, unincorporated bodies, or simply subordinate committees or working groups of the facilitator. Jurisdictions act to promote and facilitate adoption in their area, including by developing relevant country or industry taxonomies. At the time of writing, the ·IASCF was unique in not representing a country. This situation comes about by way of its supra-national characteristics. |
·LRR |
The Link Role Registry, a publicly accessible database that allows advanced users of XBRL to define new types of relationships between reporting terms [LRR]. |
·period |
The date or time to which a fact in an ·instance document relates. It can be a point in time (e.g., December 31, 2002) which is referred to as an “instant” but is also known as a “stock” figure amongst some reporting communities (especially statistics). Alternatively a period can be referred to as a “duration” which is a reporting period that extends over a known time (e.g., the 12 month period ending December 31, 2002). Statisticians refer to this second type of period as a “flow”. |
·semantics |
The meaning of an expression. The semantics of the various parts of ·XBRL itself are defined in the ·specification, but this is unlikely to be of interest to most end-users. Users of ·XBRL can create their own semantics in at least two ways. The creation of taxonomies by defining reporting terms and the way that they relate to each other is the most common way that ·XBRL allows the creation of comprehensive meanings. However, where it is possible to extend the ·XBRL itself (for instance by creating a new type of relationship in the ·LRR) it is necessary to define the meaning of that relationship. |
·specification |
The technical set of rules that governs the syntax and fundamental semantics of all ·XBRL materials, both the definitions that create ·XBRL dictionaries or taxonomies and the data, or instance documents. This is the main intellectual property of ·XII. |
·spec |
Shorthand for the ·specification. |
·SWG |
The ·XII Specification Working Group. This ·XII members-only working group maintains the ·specification and develops foundation-level modules and participates in the development of modelling rule-level documentation. |
·syntax |
The structure of a language, according to a set of rules. The syntax of ·XBRL is defined by the ·specification, as well as a number of other ·XML specifications, including several important W3C standards: XML Schema, Xlink and Xpath. |
·stylesheet |
See ·XSLT. |
·tag |
Another (less precise) term for an ·element. "Tagging" means to associate appropriate elements with the concepts in a business report. |
·taxonomist |
A professional ·taxonomy developer, concerned, primarily with the logical organisation of reporting concepts that exist in a particular domain, whether that be at the level of group internal reporting, external corporate reporting, the capture and definition of industry key performance indicia, or an accounting framework promulgated by an accounting standards setter. |
·taxonomy |
An organised group of ·XBRL definitions that together provide meaning to reporting concepts. Taxonomies are used to define accounting, financial and non-financial reporting terms in a disciplined manner. Taxonomies are often produced by a central group, for instance the jurisdictional efforts to develop the US-GAAP, IFRS, UK-GAAP or Canadian GAAP taxonomies. Taxonomies can equally be developed by a government agency or regulator to define their specific regulatory information needs. Examples include the FDIC, FSA, APRA, Danish Companies and Commerce Authority. Taxonomies comprise several files. Every taxonomy has a schema document that provides: · a code for each concept that needs to be communicated · a data type (such as monetary, string, Boolean) · some reporting specific information such as whether the time that a fact is to be reported should be measured as an “instant” (a moment in time such as “31 December 2005”) or “duration” (a period in which some activity has been measured, such as the period commencing 1 January 2005 and ending 31 December 2005”); and · sometimes certain accounting specific information such as whether a monetary item should be considered to be a natural credit balance or natural debit balance. Taxonomies also contain several linkbases. Linkbases are organising files that provide various types of information that can be used to define concepts. The usual linkbases are: · a label linkbase that provides a caption or label for each concept, in one or more languages. Special labels for verbose descriptions of a concept can also be defined in this file. · a reference linkbase that provides a link from a concept to authoritative literature that defines it, such as an accounting standard or regulatory standard. · a presentation linkbase that provides a default order for a group of concepts · a calculation linkbase that provides a default way of calculating totals and sub-totals for related concepts that have the same context · a definition linkbase that describes certain special attributes of reporting facts, such as equivalence between two concepts. Shortly, ·XII will publish another type of linkbase specification – a Formula Linkbase that allows sophisticated mathematical and logical operations to be carried out on taxonomy concepts, so as to allow the creation of validation and derivation rules. |
·Taxonomy Recognition Process (TRP) |
The TRP is a set of policies that are applied by XII around the recognition of taxonomies at two levels: Acknowledged Requires that the ·taxonomy is ·XBRL valid, is endorsed by the body that has developed, is freely accessible (that is, without royalty payment and without any other restriction), and has been documented in accordance with the requirements set out in the TRP. Acknowledged taxonomies can be in use, or they can be under development on their way to eventual recognition as Approved. Approved Requires that the ·taxonomy be acknowledged and ·FRTA conformant. Approved taxonomies must have been held open for public comment for at least a 45 day period. Additional documentation requirements include the provision of at least 2 sample ·instance documents. |
·tuple |
A set of related facts that need to be expressed and read together. It can best be thought of as a row in a table. Tuples are defined in taxonomies and used in instance documents for exactly that. |
·XBRL |
eXtensible Business Reporting Language: The language for defining, producing, exchanging, and disseminating business reports. |
·XBRL Compliant |
There is no such certification at this time. ·XII has not yet produced any sort of test programme or compliance “Kite mark”. Vendors are able to advise whether or not their tools are able to process the ·specification, ·FRTA or ·FRIS conformance suites, but this is self-certification and is not endorsed by ·XII. |
·XII |
XBRL International Incorporated. The not-for-profit global consortium, based in New York, that developed and manages the base ·XBRL technology and through its member jurisdictions facilitates the creation of ·XBRL taxonomies. |
·XML |
eXtensible Markup Language. The foundation for virtually all computer to computer interaction via the Internet. Developed by the World Wide Web Consortium (W3C). ·XBRL is a based on XML. |
·XSLT |
Extensible Stylesheet Language Transformations. One of the most prevalent technologies used to format and reformat ·XML documents, including ·XBRL. Also called stylesheets. |