Ever wondered what is XBRL ? If yes, then follow through the following post, where CA Mehul shah, a very good friend of mine and more importantly an XBRL expert, tries to explain the fundamentals and more about XBRL. And the best part is, should you have any query you can always speak to him at mehul@raseshca.com or at www.raseshca.com.
Here goes the XBRL, in words of CA Mehul shah:
"Concept
of 'XBRL'
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 1000 . 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
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).
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.
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 .
It opens () and closes ( ) 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 ).
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.
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
|
||||
Revenues
|
+
|
1,000
|
+
|
1,000
|
+
|
1,000 (Cr)
|
Cost of sales
|
-
|
1,200
|
+
|
-1,200
|
-
|
1,200 (Dt)
|
Gross profit (loss)
|
=
|
-200
|
=
|
-200
|
=
|
-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">
|
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.
xlink:href="schema.xsd#Assets"
xlink:label="Assets_Locator"/>
|
xlink:href="schema.xsd#CurrentAssets"
xlink:label="CurrentAssets_Locator"/>
|
xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child"
xlink:from="Assets_Locator"
xlink:to="CurrentAssets_Locator"/>
|
Let's analyze this example. First, we create a locator ()
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 is a child of
.
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.
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.
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.
xlink:arcrole="http://www.xbrl.org/2003/arcrole/summation-item"
xlink:from="GrossProfit"
xlink:to="RevenueTotal"
order="1" weight="1"
use="optional"/>
|
xlink:arcrole="http://www.xbrl.org/2003/arcrole/summation-item"
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.
Presentation
|
Calculation
|
||||||
Assets (Presentation)
|
|
Assets, Total
|
|
||||
|
Assets, Non-Current
|
|
|
Assets, Non-Current
|
+1
|
||
|
Assets, Current
|
|
|
Assets, Current
|
+1
|
||
|
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.
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 link base
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.
xlink:role="http://www.xbrl.org/2003/role/presentationRef"
xlink:label="CashFlowsFromUsedInOperationsTotal_ref">
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
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 ‘Cash And Cash Equivalents’.
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.
xlink:label="ifrs_AssetsTotal_lbl"
xml:lang="en">Assets, Total
|
xlink:label="ifrs_AssetsTotal_lbl"
xml:lang="de">Vermögenswerte, Gesamt
|
xlink:label="ifrs_AssetsTotal_lbl"
xml:lang="pl">Aktywa, Razem
|
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.
xlink:role="http://www.xbrl.org/2003/role/label"
xlink:label="ifrs_AssetsTotal_lbl"
xml:lang="en">Property, Plant and
Equipment, Net
xlink:role="http://www.xbrl.org/2003/role/periodStartLabel"
xlink:label="ifrs_AssetsTotal_lbl"
xml:lang="en">Property, Plant and
Equipment, Net, Beginning Balance
xlink:role="http://www.xbrl.org/2003/role/periodEndLabel"
xlink:label="ifrs_AssetsTotal_lbl"
xml:lang="en">Property, Plant and
Equipment, Net, Ending Balance
|
The example above shows how three different labels are assigned to one
element by applying different role attributes on labels.
-CA Mehul shah
mehul@raseshca.com"
Till next time
Niks
Disclaimer: The views expressed herein are the views of the guest author, CA Mehul shah, and does not necessarily represents the official views of blog. In case of any discrepancy or query the author can be reached at mehul@raseshca.com.
2 comments:
Did everything but can’t remember the abatements, the exemptions, the sections?
Remembering SERVICE TAX just got SIMPLER and more FUN!
Master SERVICE TAX with colorful pictures, mnemonics, stories and shortcuts in just 2.5 hours!
Download your free copy of ‘SERVICE TAX DECODED’ on www.servicetaxdecoded.com! Over 1250 copies downloaded on the day of release!
Whether you’re a student or a professional, these addictive codes won’t let you forget SERVICE TAX, even if you want to! The book has been scientifically designed on tested principles of memory expansion and retention!
Visit www.servicetaxdecoded.com and download your free copy now!
Learn better! Be different! Stand out!
The author CA Samiksha Jain is a ranker throughout, felicitated for 100 marks in two subjects in the IPCC examination and for the best paper in subject - Law in the CA Final Examination. She attributes her success to use of these You make us feelmemory techniques.
Very lucidly expressed , thank you for explaining each and every nitty gritty in details.
Post a Comment