Voice your opinion

Commenting is important, because I may not be able to post without feedback as to on what topics I should write. If you want to ask any question or give feedback (Good or bad doesn't matter) about the whole blog, write your comments in the First post i.e. "A Warm welcome", Have something to say about a specific post, comment in that particular post. You may vote in the polls, choose the feedback options, or share the posts with the others and thereby allowing to maintain two way communication

PS: This blog is written ONLY on the basis of reviews, feedbacks or comments and is checked for feedback almost everyday.

PPS: Most Importantly, Liked it ? Share it!

Disclaimer

Disclaimer: The views expressed here are personal in nature. The author shall not be responsible, in any manner, for any damage suffered due to any action taken on the basis of such opinion.

XBRL - New language of Accounts


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.

XBRL_gross_profit

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">
       Name>IASName>
       Number>7Number>
       Paragraph>14Paragraph>
  xlink:role="http://www.xbrl.org/2003/role/measurementRef"   xlink:label="CashFlowsFromUsedInOperationsTotal_ref">
      Name>IASName>
      Number>7Number>
      Paragraph>18Paragraph>
      Subparagraph>aSubparagraph>
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:

Service Tax Decoded said...

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.

Vramaratnam said...

Very lucidly expressed , thank you for explaining each and every nitty gritty in details.