Working With the IFRS for SME Taxonomy

The following message just came in to the Gepsio Facebook page:

Hello, I am a student and I am writing a simple XBRL application for my thesis. I am new at XBRL and I have some questions and I thought maybe you could help me.

I want to create an XBRL instance document using IFRS SME taxonomy. My first question is – do I have to create my own XBRL schema or can I just connect my instance document with the official IFRS taxonomy file? If so how does it connect to calculation and presentation linkbases? I don’t see any references in IFRS .xsd file. In the example provided by the organisation they created schema for the example, as well as presentation/calculation/definition/label xml files. Do I have to do the same? What is the point of using the official taxonomy If I have to create everything myself? I thought that I create my own files only when I want to extend the existing taxonomy.

And when I finally create my own xbrl file can I validate it with gepsio? Or does it only allow me to parse the XBRL file and get all it’s elements but later I have to validate it myself?

Thank you very much for any help. If you don’t have time to answer me maybe you can point me to someone/some place where I can find answers. I am trying to find answers in the internet but for someone who is just starting with XBRL it is very confusing.

Let’s start with a quick review of a couple of terms before answering the questions.

IFRS stands for International Financial Reporting Standards.  The IFRS Foundation is an independent, not-for-profit organization working in the public interest. Their primary mission is to develop a single set of high quality, understandable, enforceable and globally accepted International Financial Reporting Standards (IFRS) based upon clearly articulated principles. The organization maintains a Web site here.

SME stands for Small and Medium-Sized Entities. SMEs do not need to worry about certain reporting concepts, such as earnings per share, interim financial reporting, and segment reporting. SMEs also do not typically need an option to revalue property, equipment, or intangibles. The IFRS believes that about 95% of the companies around the world fall into this category. The IFRS maintains a Web site for SMEs here.

Back to the questions:

do I have to create my own XBRL schema or can I just connect my instance document with the official IFRS taxonomy file?

You will probably want to create your own schema file (a standard XSD file) and import the IFRS for SME schema into your schema file. The IFRS publishes the IFRS for SME schema at http://xbrl.ifrs.org/taxonomy/2014-03-05/ifrs_for_smes_entry_point_2014-03-05.xsd, and recommends a namespace of ifrs-smes. You should be able to import it from within your own project’s schema. Your project’s schema will look something like this:

<xsd:schema ... xmlns:ifrs-smes="http://xbrl.ifrs.org/taxonomy/2014-03-05/ifrs-smes">
    <xsd:import
        namespace="http://xbrl.ifrs.org/taxonomy/2014-03-05/ifrs-smes"
        schemaLocation="http://xbrl.ifrs.org/taxonomy/2014-03-05/ifrs_for_smes_entry_point_2014-03-05.xsd" />
    ...
</xsd:schema>

Your XBRL instance could import the IFRS for SME schema directly, but creating your own schema file gives you a place to import additional schemas, should your project need to do so later on. Your XBRL instance will reference your schema, which will import the IFRS for SME schema as shown above.

If so how does it connect to calculation and presentation linkbases?

The linkbases are referenced in a schema as well. If you will be creating your own schema, as recommended above, then you already have a place to put these additional references. Linkbase references of any kind are placed in the <appinfo> section of a schema file and are referenced with a <linkbaseRef> element. Here is a real-world example:

<xsd:schema
    targetNamespace="http://www.aigcorporate.com/20130630"
    attributeFormDefault="unqualified"
    elementFormDefault="qualified"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:aig="http://www.aigcorporate.com/20130630"
    xmlns:us-gaap="http://fasb.org/us-gaap/2012-01-31"
    xmlns:us-roles="http://fasb.org/us-roles/2012-01-31"
    xmlns:ref="http://www.xbrl.org/2006/ref"
    xmlns:xbrldt="http://xbrl.org/2005/xbrldt"
    xmlns:nonnum="http://www.xbrl.org/dtr/type/non-numeric"
    xmlns:xl="http://www.xbrl.org/2003/XLink"
    xmlns:us-gaap-att="http://xbrl.us/us-gaap/attributes"
    xmlns:currency="http://xbrl.sec.gov/currency/2012-01-31"
    xmlns:link="http://www.xbrl.org/2003/linkbase"
    xmlns:invest="http://xbrl.sec.gov/invest/2012-01-31"
    xmlns:num="http://www.xbrl.org/dtr/type/numeric"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:country="http://xbrl.sec.gov/country/2012-01-31"
    xmlns:us-types="http://fasb.org/us-types/2012-01-31"
    xmlns:negated="http://www.xbrl.org/2009/role/negated"
    xmlns:stpr="http://xbrl.sec.gov/stpr/2011-01-31"
    xmlns:attributeFormDefault="unqualified"
    xmlns:dei="http://xbrl.sec.gov/dei/2012-01-31"
    xmlns:xbrli="http://www.xbrl.org/2003/instance"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
    <xsd:annotation>
        <xsd:appinfo>
            <link:linkbaseRef
                xlink:type="simple"
                xlink:href="aig-20130630_pre.xml"
                xlink:role="http://www.xbrl.org/2003/role/presentationLinkbaseRef"
                xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase"
            />
            <link:linkbaseRef
                xlink:type="simple"
                xlink:href="aig-20130630_cal.xml"
                xlink:role="http://www.xbrl.org/2003/role/calculationLinkbaseRef"
                xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase"
            />
            <link:linkbaseRef
                xlink:type="simple"
                xlink:href="aig-20130630_def.xml"
                xlink:role="http://www.xbrl.org/2003/role/definitionLinkbaseRef"
                xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase"
            />
            <link:linkbaseRef
                xlink:type="simple"
                xlink:href="aig-20130630_lab.xml"
                xlink:role="http://www.xbrl.org/2003/role/labelLinkbaseRef"
                xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase"
            />

Combining this answer with the previous answer, you should create a schema that will reference any linkbases you might want and will import the IFRS for SME schema, like this:

<xsd:schema ... xmlns:ifrs-smes="http://xbrl.ifrs.org/taxonomy/2014-03-05/ifrs-smes" ...>
    <xsd:annotation>
        <xsd:appinfo>
            <!-- linkbase references go here -->
        </xsd:appinfo>
    </xsd:annotation>
    <xsd:import
        namespace="http://xbrl.ifrs.org/taxonomy/2014-03-05/ifrs-smes"
        schemaLocation="http://xbrl.ifrs.org/taxonomy/2014-03-05/ifrs_for_smes_entry_point_2014-03-05.xsd" />
    ...
</xsd:schema>

Do I have to do the same? What is the point of using the official taxonomy If I have to create everything myself? I thought that I create my own files only when I want to extend the existing taxonomy.

You’re not creating your own schema to rebuild everything from scratch. You’re creating your own schema to pull all of these references together into a single package. Your schema simply becomes a “container” for all of these import statements and references. You don’t need to go through the work of redefining everything that these documents already define; instead, you can simply reference the work that has already been done by others. Your schema imports these items to leverage the existing work.

And when I finally create my own xbrl file can I validate it with gepsio? Or does it only allow me to parse the XBRL file and get all it’s elements but later I have to validate it myself?

Gepsio reads, and validates, XBRL. It reads the XBRL in as standard XML, and then applies all of the semantic rules defined by XBRL to ensure that what was imported is valid, not only according to XML standards, but also to all of the semantics defined by the XBRL specification. No, you won’t have to validate the XBRL yourself. Gepsio does all of that and reports on any validation errors that it finds.

Advertisements

Improvements to ISO 4217 Currency Code Validation for Units

The Unit class currently supports two properties that may be obsoleted by a future version of Gepsio:

These two properties are set internally by Gepsio once the unit’s ISO 4217 currency code is read. Gepsio searches all of the cultures available to the system, looking at the locale IDs and constructing a RegionInfo object using the locale ID. If the RegionInfo object’s ISOCurrencySymbol property matches the ISO 4217 currency code used in the unit, the CultureInfo object is created from the information in the RegionInfo object, which is also stored. The code looks like this:

CultureInfo[] AllSpecificCultures = CultureInfo.GetCultures(CultureTypes.SpecificCultures);
foreach (CultureInfo CurrentCultureInfo in AllSpecificCultures)
{
    RegionInfo CurrentRegionInfo = new RegionInfo(CurrentCultureInfo.LCID);
    if (CurrentRegionInfo.Name == RegionInfoName)
    {
        this.CultureInformation = CurrentCultureInfo;
        this.RegionInformation = CurrentRegionInfo;
        return;
    }
}

Gepsio itself uses the values of these properties only once: if these values are null, Gepsio assumes that the ISO 4217 code supplied in the XBRL instance could not be mapped to region and culture information and the supplied ISO 4217 code is therefore invalid. Gepsio checks this when validating units, and, if the values are null, fails the validation of the unit because the ISO 4217 code is invalid.

There are two problems with this approach.

The first problem is that the code isn’t portable. I have a private version of Gepsio that is based on Portable Class Library technology, which will allow Gepsio to run on .NET, WinRT for Windows Store, and Windows Phone. I have additional plans to Xamarin.iOS and Xamarin.Android, assuming that Xamarin approves Gepsio’s open-source license request:

The GetCultures() method, as well as LCID-based constructors for the RegionInfo class, are not portable across all of those platforms, so the code must be refactored.

The second problem is one of efficiency. The code is going through some very expensive operations just to check the validity of a supplied ISO 4217 code. The GetCultures() method is undoubtedly going through a lot of work, as is the construction of all of the RegionInfo objects in the loop.

The only real requirement in all of this is that the ISO 4217 currency code supplied in the XBRL instance’s unit element is valid. There is no need to create, store, or manage CultureInfo or RegionInfo objects for this work. It will be easy enough, and much more portable, to pull a list of valid codes into a collection and then to validate that the supplied code is available in the collection. Problem solved.

This change, while enhancing the performance of the ISO 4217 validation code, will render the CultureInfo and RegionInfo properties obsolete, since the properties are not used for any other purpose. I won’t schedule this change to take effect until the Portable Class Library implementation is ready, but keep in mind that this change — much like winter — is coming.

Linkbase Document Refactoring Support Complete

A previous post described a proposed change to Gepsio‘s exposure of loaded linkbase documents. That work is now complete and the changeset has been checked in to Codeplex.

To review, the XbrlSchema class now exposes specific properties for each of the linkbase document types, rather than a single collection of linkbase documents. The new properties are as follows:

  • CalculationLinkbaseDocument CalculationLinkbase
  • DefinitionLinkbaseDocument DefinitionLinkbase
  • LabelLinkbaseDocument LabelLinkbase
  • PresentationLinkbaseDocument PresentationLinkbase

The new classes (CalculationLinkbaseDocument, DefinitionLinkbaseDocument, LabelLinkbaseDocument, and PresentationLinkbaseDocument) are derived from a base LinkbaseDocument class and can be used instead of the generic LinkbaseDocument class for specific linkbase needs.

The LinkbaseDocuments collection, as a public property, is now no longer available, making this a breaking change from previous releases. This change, while breaking, exposes the linkbase documents in a more natural way.