Welcome to the website of the IFRS Foundation and the IASB

Wednesday 16 April 2014

Banner graphic


This page is devoted to an introduction to some basics of XBRL. It provides explanations of the major terms underlying this concept.

The target audiences are non-technical (IT) and non-accounting people who would like to understand both a bit of XBRL code and some of the problems that are tackled in order to allow computers to process and communicate accounting data meaningfully.

If you have questions of a more generic nature, such as "How did it all start?" , "Who owns XBRL?" or "What are the benefits?", please visit the XBRL International Website

Calculation Linkbase

Definition Linkbase




Instance Document

Label Linkbase


Presentation Linkbase

Reference Linkbase



Taxonomy Extension



XBRL stands for eXtensible Business Reporting Language. It is an XML (eXtensible Mark-up Language) dialect developed for business reporting purposes.

In XBRL, financial data is tagged so that it can be easily understood and processed by computers, for example <Asset>1000</Asset>. The word Asset together with brackets "<" and ">" is called a tag. We distinguish opening tags: <…> and closing tag: </…>. Between the tags there is a value. What computers understand from the example above is that something called an Asset has the content “1000”. But how do they know what an Asset is?

This is where XBRL uses computer scientists’ concept of metadata. In brief, metadata is data about data. For example, a programmer has to explain to a computer how it should understand the term Asset and what kind of values could be assigned to this concept.

From the accounting perspective, Asset should have a monetary value (type attribute) and its balance nature is debit. This refers to the basic rule of double entry accounting that Assets and Expenses have normal balance of a debit while Equity, Liabilities and Revenues have a normal balance of a credit (see balance attribute).

Another characteristic of an Asset is that it is a resource available to an entity at a particular point in time. It appears on the Balance sheet which is a snapshot of an entity’s financial position at a specified date. The opposite of a resource presented at a point of time is a flow which occurs during a period (see period type attribute).

The description above shows that information about at least three characteristics must be provided to a computer so that it can understand <Asset> in an accounting manner.

Of course, thousands of hours spent on developing XBRL were not devoted to only tell computers what an Asset is. In accountancy there are many concepts that could be described using XBRL. Moreover, there are different regulations concerning financial reporting which means that the definition of an Asset under IFRSs (International Financial Reporting Standards) could be different to the one provided by some national GAAPs (Generally Accepted Accounting Practices/Principles).

Therefore, there is a need to describe interactions between financial concepts for each regulation of GAAP. This is to define whether or not there is any relation between Assets and for example Receivables and if there is, how it looks it terms of accounting knowledge and create references for elements to express to which accounting act they apply to. To do that, XBRL uses technology called XML Linking (XLink).

To relate the information provided above to the main drawing at the top we could say that:

  • values between tags (for example <Asset>100</Asset>) are found in instance documents;
  • information on what an Asset is and how a computer should treat it is provided in schema files;
  • relationships are described in linkbases which are segregated into different categories depending on what is described and how it is done.

 The following sections discuss each of the elements of the diagram in more detail.


The word 'taxonomy', according to the Wikipedia, is derived from Greek verb tassein which means to classify and noun nomos that could be translated into English as law or science. Combined and interpreted word for word it would mean classification of some kind of knowledge. Initially, it referred to the science of classifying living things, but later it received wider meaning and is currently applied to either classification of things in general or rules governing this classification.

Frequently, taxonomies are given hierarchical structures or are built in the form of networks so, as well as the elements, they also represent relationships.

Virtually everything could be a subject of classification under some taxonomy. The most common example of taxonomy is classification of living creatures. The root element (the most general one) is Organism since all living things are of this group. Its first child is Domain which in turn is a parent of Kingdom whose subgroup is Division that is divided into Classes and so on.

One important characteristic of taxonomies is that children (lower level elements) may have many parents (upper level elements). In some classifications, spiders could be categorised as insects, in others as eight-legged creatures and in another as non-flying organisms.

Now, how does this term apply to XBRL?

In XBRL, a taxonomy consists of the core part which is a schema (or more schemas) and linkbases. If you compared it to the physique of a crab, the schema would be its head and trunk (where all the major organs are situated) and the linkbases would be its limbs. Of course, a schema could exist without linkbases in the same way as that a crab could theoretically live without limbs but in order for crab to survive and for the taxonomy to be optimal both parts of the body are necessary.

Relating the XBRL taxonomy to the general taxonomy term explained above the schema is the part that contains definitions of elements (such as Assets) whereas linkbases provide relationships between them. In the example of the classification of living things, the explanation of what is an Organism, Domain, Kingdom, Division and Class would be placed in the schema while the hierarchical relationships between them would appear in the linkbases.

Click on the links to learn more about schema and linkbases and see some examples.


An XBRL schema stores information about taxonomy elements (their names, ids and other characteristics). It can be regarded as a container where an unstructured list of elements and references to linkbase files are described.

From the technical point of view the XBRL Schema is an XML Schema tailored to particular business and financial reporting needs. The schema itself represents a set of unrelated elements. Schemas are created using XML Schema technology and their physical form is a file with an extension .xsd. Together with linkbases it creates an XBRL taxonomy.

The root element (the most general one) of all schemas is <schema>. It opens (<schema>) and closes (</schema>) every schema document. It contains some attributes describing it. Because the same element could be defined in many schemas each of which would assign it a different meaning (for example under various GAAPs the concept Assets may be defined differently), to distinguish between the elements we use namespaces. Namespace look like Internet addresses (for example http://xbrl.iasb.org/int/fr/ifrs/) but they are not.

The reason for using names that look like www locators (URIs) is that they are unique and therefore are appropriate to identify the elements that are unique to a schema. Instead of using the whole, long address we can assign it a prefix. If we define for example that ifrs=http://xbrl.iasb.org/int/fr/ifrs/ then, instead of quoting the whole URI before an element name, we can simply use ifrs (for example <ifrs:Assets/>).

To summarize, the main purpose of XBRL schemas is to provide the computer with information on how it should represent and process accounting terms. As explained in the XBRL section, computers do not have built-in accounting knowledge so they have to be taught what a particular concept means and what its characteristics are. To learn more on how to explain accounting to a computer go to the Element section.


An element is a business concept (such as Assets, Liabilities, Income…) presented to a computer in a way that it could learn its main characteristics. To achieve this, definitions of elements that appear in schemas are constructed according to a specific set of rules. The example below describes simplified (prefixes have been omitted) definition of the element Assets.

<element name=”Assets” id=”Assets” periodType=”instant” balance=”debit” abstract=”false” substitutionGroup=”item” type=”monetaryItemType”/>

The most important parts provided in this example, from a business perspective, are name, type, balance and periodType.

It is easy to guess that the first component assigns an element a unique name. To distinguish between elements defined in different schemas we use namespaces and their prefixes (see schema section). A name must meet several criteria and cannot contain spaces and other characters that are 'illegal' in XML. XML distinguishes between upper and lower case so 'assets' and 'Assets' are different elements.

Apart from the name, for an accountant, the concept Assets is associated with a set of characteristics that are defined by other components presented in the example above.

periodType relates to the accounting distinction between flows and resources. Since it is natural to provide a value of Assets for a particular date and time (usually the end of the year), the value of this attribute for this concept is set to "instant". Flows such as Payments, Revenue or Profit would have "duration" as periodType.

Another characteristic of accounting that computers have to learn is the balance nature of an element. According to the basic rule of double entry accounting, Assets and Expenses are have normal balances in 'debit' while Equity, Liabilities and Revenues have normal balances in 'credit'. So to increase an Asset or Expense, you 'debit' the account and to decrease them you 'credit' the account.

To reflect this feature in XBRL, each element (or more precisely: each item) than falls into one of these categories and has a monetary value should contain in its definition a specification of whether it has a normal 'debit' or 'credit' balance. This requirement was introduced because of the need of having comparable data and because it is necessary in order to perform accounting calculations.

For example the element Cost of sales (an Expense) could be assigned negative value and added to Revenue ('credit') in order to calculate Gross profit or it could be a positive figure which by subtraction from Revenue would give the same result.


No balance attribute assigned

Balance attribute assigned







1,000 (Cr)

Cost of sales






1,200 (Dt)

Gross profit (loss)






-200 (Cr)

Although using a balance attribute is useful and straight forward in the case of Balance Sheets or Income Statements, it creates difficulties in calculating some Cash Flows in which elements do not necessarily obey 'credit'/'debit' rules. There are new technologies under development such as formulas and functions that make XBRL more programmable and so are likely to be helpful with the problem.

Last but not least important characteristic of an element that has to be defined is its type. In financial reports companies include information that are in the form of figures with monetary units (e.g. £100), numbers (for example number of employees), percents (interest rates), strings (regular text) and others.

To help computers know how to treat each of these, XBRL developers decided to use (with small adjustments) XML built-in types. By doing so, computers can check the validity of data entered according to the type as well as make calculations. The most common types that appear in financial statements are monetaryItemType, stringItemType and decimalItemType.

There are some concepts in business reporting that are expressed in XBRL using elements whose definitions and constructions differ significantly from presented above. They are called tuples and were designed to express, for instance, tables with unknown number of rows or columns. A simplified (prefixes have been omitted) example is provided below:


 id="Deposit" name="Deposit" substitutionGroup="tuple" nillable="true">



      <restriction base="anyType">


          <element ref="Description" />

          <element ref="Amount" />

          <element ref="EffectiveInterestRate" minOccurs="0" />


        <attribute name="id" type="ID" use="optional" />





The first feature that distinguishes them from regular elements is that their substitutionGroup value is set to tuple (in contrast to the previous example where this attribute was assigned the value item).

Secondly, the definition of the element Deposit lacks many of the components described above such as balance attribute, periodType or type. Instead, this element contains other elements which are, in the example provided, Description, Amount and EffectiveInterestRate. The definition of the content a tuple may hold includes additional information concerning the order of elements contained and their minimum number of occurrences (minOccurs) and maximum number of occurrences (maxOccurs).

Unlike regular items, tuples (and items that they contain) may appear in instance documents several times in the same context. Relating this to the example above, the reporting entity may define a list of deposits by providing the Description, Amount and Effective Interest Rate of each.

Once elements and their features are defined in a schema, taxonomy creators face the task of providing computers with knowledge on relations between elements and their links with human readable resources. These constitute components of linkbases.


As described in the taxonomy section, linkbases (often referred to as 'layers') are the components of a taxonomy that provide information about relationships between elements and link them with specified external resources. So typically, as well as defining XBRL elements, the creation of an XBRL taxonomy, regardless of its purpose, also involves performing following actions:

  • labeling elements in specified languages in order to make taxonomy readable for humans;
  • referencing elements to the external resources that justify their existence and that contain an explanation, definition or example of the use of the particular financial concept,
  • defining relations between elements according to different criteria.

The figure at the top of the page presents how linkbases relate to the schema. There are unidirectional arrows to the label and reference linkbases and bidirectional ones to the presentation, calculation and definition layers.

The actions listed in the bullet points above are the five types of linkbases represented in the diagram. Label and reference linkbases connect elements to external resources, while presentation, calculation and definition layers provide descriptions of relationships between elements.

Linkbases use two XML technologies. The first is known as XLink (XML Linking Languages) which as its name suggests, allows for the creation of hyperlinks in XML documents. The second is XPointer (XML Pointing Languages) that helps to localize specific parts of XML and XBRL documents (e.g. elements' definitions in schemas).

Basically, in order to create a relation, we need to point to elements or resources that we are interested in and define the type of relationship. A simplified example of a hierarchical relation from a presentation linkbase is provided below.

<loc xlink:type="locator"



<loc xlink:type="locator"



<presentationArc xlink:type="arc"


 xlink:from="Assets_Locator" xlink:to="CurrentAssets_Locator"/>

Let's analyze this example. First, we create a locator (<loc>) which we label Assets_Locator and we point to the element that is defined in the schema stored in the file schema.xsd whose id attribute value is Assets. Lines three and four repeat this action for the element CurrentAssets.

The last three lines describe the relation between the “located” elements by describing the type of connection. An arcrole attribute defines the type of relation which in this particular case is ”../parent-child” (hierarchical order). The attributes to and from point to locators. In the example the relation says that <CurrentAssets> is a child of <Assets>.

To sum up, linkbases provide descriptions of connections between elements by localizing them and defining the type of relationships (utilizing arcrole attribute). Each of the five linkbases (layers): presentation, calculation, definition, reference and label contains definitions of different types of relations.

Presentation linkbase


Business reports are in general prepared in the form of tables or statements or other structures. The presentation linkbase stores information about relationships between elements in order to properly organize the taxonomy content. This allows the elements to be arranged in a structure that is appropriate to represent the hierarchical relationships in particular business data.

These groupings can be performed in many ways. For example, a typical Balance Sheet contains Assets, Equity and Liabilities. Assets consist of Current Assets and Non-current Assets. Current Assets are split in Inventories, Receivables and so on. The presentation linkbase, using parent-child relations organizes elements in this way and helps users find concepts they are interested in.

The main drawback of a tree-like (hierarchical) structure in a presentation linkbase is that it only allows the presentation of flat lists of elements, while financial statements also contain more sophisticated reports such as Changes in Equity or Movements in Property, Plant and Equipment . The XBRL Consortium is currently working on rendering solutions that would provide for the automatic creation of such reports.

Calculation Linkbase

The idea of the calculation linkbase is to improve the quality of an XBRL report. It contains definitions of basic validation rules, which apply to all instance documents referring to a particular taxonomy. A hierarchically calculation linkbase sorts all monetary elements in this way so that lower level elements sum up to or are subtracted from one another so that the upper level concept is the result of these operations.



 The sign of the relationship depends on the weight attribute that is assigned to the arc connecting two elements. An example is provided below.


<calculationArc xlink:type="arc"


 xlink:from="GrossProfit" xlink:to="RevenueTotal"

 order="1" weight="1" use="optional"/>

<calculationArc xlink:type="arc"


 xlink:from="GrossProfit" xlink:to="CostOfSales"

 order="2" weight="-1" use="optional"/>

The example shows that there are defined two calculation arcs providing details concerning relations between Gross profit, Revenue and Cost of Sales. In Income Statements, Gross profit is a difference between the other two.

Therefore, we assign weight attribute value to “1” on the arc connecting Gross profit and Revenue and “-1” between Gross profit and Cost of Sales.

The reason why there is a difference between calculation and presentation linkbases, is that the total element that stands for the summation of all others usually appears at the bottom in the financial statements whereas in the calculation linkbase it must be placed as the top concept.




Assets (Presentation)


Assets, Total



Assets, Non-Current



Assets, Non-Current



Assets, Current



Assets, Current



Assets, Total






There two major of rules concerning calculation relations in XBRL.

Firstly, we cannot carry out operations on elements that have different values of the periodType attribute. This is often called the cross-context rule and relates to defining some elements as “For period” (duration) and others as “As of date” (instant). For example, concepts that appear on Balance Sheet are instant which means that their value is presented for a specified day, while elements in the Income Statement or Statement of Cash Flows are duration because they represent actions that took place over a period of time. The problem emerges for example in the Statement of Changes in Equity or Movements in Property, Plant and Equipment where instant elements mix with duration. The solution to this problem is a formula linkbase that will provide taxonomy creators with many more functions than just simple addition or subtraction.

Secondly, the double entry accounting rule requires XBRL taxonomy creators to define the credit/debit nature of monetary elements appearing in the Balance Sheets and Income Statements. This rule does not allow the addition of elements with opposite balance attributes (they must be subtracted). It also defines whether the value contained by an element should be positive or negative.

Definition linkbase

The definition linkbase provides taxonomy creators with the opportunity to define different kinds of relations between elements. There are four standard types of relationships supported by the definition linkbase.

The first one is referred to as “general-special”. It distinguishes between concepts that have more generic or more specific meaning. For example Zip Code is the US representation of Postal Code which is used worldwide. Therefore, to indicate that connection, taxonomy creators define Postal Code as a general term to which there is more specialised concept Zip Code.

Second available relation type is “essence-alias”. By using it, taxonomy creators are able to indicate that two concepts have similar meaning. For example, some airlines may want to use the term Planes to describe their main component of their PPE while other would prefer Aircraft. To state that meaning of these two is the same and that they can be used interchangeably, taxonomy creators may connect them using “essence-alias” arcrole.

The third standard type of relation is called “requires-element”. As its name indicates, taxonomy builders use it to force instance creators to enter the value of one element, if they provide the content of another. For instance, a regulator may want to require disclosures on a particular component of Assets if it appears on the Balance Sheet. In order to achieve that, the definition linkbase defines “requires-element” relationship between them (for example, Property, Plant and Equipment, Net and Property, Plant and Equipment Disclosures).

The fourth relation is “similar-tuples". It resembles "essence-alias" relation but is applied for tuples. It connects two tuples that are equivalents in terms of definition (documentation from label linkbase or reference in reference linkbase) but are diverse from XML perspective i.e. do not have identical content models, for example contain different elements. One of the reasons that this type of relation was introduced is prohibition of schema redefinition which disallows for changes in tuple's content model.

Reference linkbase

Financial concepts appearing on business reports more often than not stem from regulatory documents issued by authorities. For example, the IFRS Taxonomy describes financial reports prepared based on IFRSs (Bound Volume).

Elements defined by this taxonomy refer to the specific terms and concepts explained in the standards. For this reason, a taxonomy is often provided with a reference linkbase that presents relationships between elements and external regulations or standards (the other solution is to enclose documentation in label linkbase). This helps instance creators and users understand the intended meaning of each element and provides support for its inclusion in the taxonomy.

The reference layer does not contain the full text of the regulations. Instead, it points to source documents by identifying their name and indicating the relevant paragraphs and clauses. This connection is created using “concept-reference” arcrole.

There are several types of references that could be provided for each element.

<reference xlink:type="resource"







<reference xlink:type="resource"

  xlink:role="http://www.xbrl.org/2003/role/measurementRef"   xlink:label="CashFlowsFromUsedInOperationsTotal_ref">






The example above indicates references for Cash Flow from (Used in) Operations. First, it provides a reference to a document which explains how and where the element should be presented in terms of its placement and labeling. In IAS 7, paragraph 14 we read that the concept Cash Flows from Operating Activities exists and what it is derived from. Second, the measurement reference provides explanations about what determines the value of the element and how it should be calculated. This description can be found in IAS 7 paragraph 18.a.

XBRL also allows an element to be assigned other types of references containing examples, commentaries, etc

Label linkbase

XBRL aims to become a world-wide standard for electronic business reporting. This requires taxonomies to present business data in many different languages. Therefore it is important to be able to create an element that is assigned with labels for different languages. There may also be different labels for different purposes. All labels are stored and linked to the elements in a label linkbase.

Elements defined in a schema are built to convey accounting meaning to computers. In order to make it easier for computers to process their names, they have to obey some rules. For example, the use of spaces is not allowed so ‘Cash and Cash Equivalents’ would be named ‘CashAndCashEquivalents’ . Additionally, big taxonomies such as IFRS obey specific rules of naming and labelling to ensure consistency within the schema. For example, there could be a list of words that are excluded from the names (e.g. ‘and’ , ‘of’ …) or words that appear only in a particular order (i.e. ‘Net’ or ‘Total’ at the end of the label after a comma).

In the label linkbase, elements are connected to human readable labels using “concept-label" arcrole.

As mentioned above, elements can be assigned to labels in different languages. An example that describes definitions of labels of the IFRS element AssetsTotal in English, German and Polish is provided below.

<label xlink:type="resource" xlink:role="http://www.xbrl.org/2003/role/label"

 xlink:label="ifrs_AssetsTotal_lbl" xml:lang="en">Assets, Total</label>

<label xlink:type="resource" xlink:role="http://www.xbrl.org/2003/role/label"

 xlink:label="ifrs_AssetsTotal_lbl" xml:lang="de">Vermögenswerte, Gesamt</label>

<label xlink:type="resource" xlink:role="http://www.xbrl.org/2003/role/label"

 xlink:label="ifrs_AssetsTotal_lbl" xml:lang="pl">Aktywa, Razem</label>


To distinguish between languages, XBRL uses the XML attributelang. Taxonomy creators may also define different labels for one element. One of the ideas of XBRL is that the information about the period and currency for which the element is reported is not contained within an element definition but is described by a context in instance documents. In financial reporting on the other hand, many terms express the date for which they are being reported, for instance Property, Plant and Equipment at the beginning of year and Property, Plant and Equipment at the end of year. XBRL allows the creation of different labels depending on the context in which an element will be used.

<label xlink:type="resource"



 xml:lang="en">Property, Plant and Equipment, Net</label>
<label xlink:type="resource"



 xml:lang="en">Property, Plant and Equipment, Net, Beginning Balance</label>
<label xlink:type="resource"



 xml:lang="en">Property, Plant and Equipment, Net, Ending Balance</label>

The example above shows how three different labels are assigned to one element by applying different role attributes on labels.

Taxonomy Extension

Public taxonomies, such as IFRS, define elements and relationships between them according to particular legislation or standards, for example “International Accounting Standards” (IAS) or “International Financial Reporting Standards” (IFRS). These XBRL-described concepts allow companies to create financial statements that are valid and compliant with the requirements of regulators.

But in the diverse world of finance, companies are required to include in their business reports additional concepts (usually related to the area of their activity or the reporting purpose). XBRL, as its name indicates, allows for such extensions without loss of comparability and integrity of data.

Extending the taxonomy may involve performing the following operations:

  • adding an element that was not described in the base taxonomy but is required;
  • modifying the relationship between elements in terms of their order, addition or deletion.

Taxonomy extensions are built for different purposes mainly by regulators, local authorities or simply by reporting companies.

There are several rules that have to be obeyed while building an extension taxonomy. The most important one states that the extension should not physically modify the content of any of the files of the base taxonomy. This is usually made impossible by locating the base taxonomies on their website which prevents other users from making changes to the files.

Building an extension that involves the modification of linkbases requires that the creators are familiar with the attributes use and priority as well as the concept of equivalency. With these attributes you can prohibit a relation (an arc) or override it. The use attribute may take the values “optional” and “prohibited” of which the latter implies that the relationship will not be processed by a computer. priority assigns relations with ranks that inform the computer about the processing order.


DTS stands for Discoverable Taxonomy Set. It contains one or more taxonomies i.e. a number of schemas together with linkbases related to them. This term was developed as taxonomies became more complicated and more closely related to each other.

A complete set of the IFRS Taxonomy (which graphical presentation can be viewed on the diagram placed on the summary page) consists of 47 files (including three schemas). Moreover, this taxonomy is usually approached using another entry schema generated by the ITMM (IFRS Taxonomy Modules Manager).

This so-called ‘shell’ schema imports IFRS main schema that defines all elements and refers to selected linkbases containing presentation and calculation relationships as well as labels in different languages.

Instance Document

An XBRL instance document is a business report in an electronic format created according to the rules of XBRL. It contains facts that are defined by the elements in the taxonomy it refers to together with their values and an explanation of the context in which they are placed.


Element’s definition:








   nillable="true" />

Instance Document

Business fact:






<unit id="U-Euros">




<context id="Current_ForPeriod">


 <identifier scheme="http://www.sampleCompany.com">









The example above states that Sample Company’s Profit Loss Before Tax for the year 2004 amounted to 661,000 EUR. As you can see, element’s definition is contained in the schema. The instance document assigns it a value and provides additional information about the currency in which it is disclosed and defines a period and the entity that it refers to.


Footnotes appear on instance documents and provide additional information for some of the elements. If for example, in a business report, several concepts refer to the statement “For more information see Disclosures on Assets”, it is possible to create linkages between them and a footnote element containing this block of text.

<Assets id="Assets"

 decimals="0" contextRef="Current_AsOf" unitRef="GBP">20000</Assets>

<link:loc xlink:type="locator" xlink:href="#Assets" xlink:label="Assets"/>

<link:footnoteArc xlink:type="arc"


 xlink:from="Assets" xlink:to="AssetsFootnote" order="1.0"/>

<link:footnote xlink:type="resource" xlink:label="AssetsFootnot"


 xml:lang="en">For more information see Disclosures on Assets</link:footnote>

In the example above, the first lines provide us with a description of the fact that Assets reported in the current period amounted to 20,000 GBP and creates a locator that point to this statement. The element footnote contains the text of a footnote and the footnoteLink connects the element with this reference.